At 09:27 02/04/03 -0800, Alexandre Julliard wrote:
Adam Gundy arg@cyberscience.com writes:
which part of the signal stuff won't work? all that has happened is that the "kill( <pid>, SIGUSR1 )" has moved from the wineserver to the client (for 'local' threads). I thought that the NPTL stuff still wanted a PID-per-thread model just so it can do this?
No you can't use kill, you have to use pthread_kill, but then it will break the non NPTL case. And on Solaris you have to do some lwp stuff instead. Basically there is quite a bit of complexity that the server takes care of that you would have to replicate in the client.
Solaris isn't an issue here - valgrind only works on linux/x86.
I haven't seen the WINE NPTL code, but... is there any particular reason that you have to use pthread_kill()? further down in your response you said:
Well, sending a signal to a thread from another process is standard Linux functionality, so I'd argue that valgrind should support it one way or another.
which surely implies that it is OK to use kill() instead of pthread_kill() as a mechanism for sending signals to a thread... I assume that under NPTL pthread_kill() is just a thin wrapper for kill() anyway?
as to making valgrind use real threads, I think that is a BIG job, and unlikely to happen, since the only thing that wants 'real' threads is WINE - everything else is happy with pthreads.
Well, sending a signal to a thread from another process is standard Linux functionality, so I'd argue that valgrind should support it one way or another.
true, if by 'thread' you mean 'cloned thread'. Changing valgrind to _really_ support the clone() system call is a huge job... if it can even be done.
Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.