valgrind for WINE

[Adam Gundy]

At 09:27 02/04/03 -0800, Alexandre Julliard wrote:
>Adam Gundy <arg at 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.