valgrind for WINE

[Adam Gundy]

At 21:44 03/04/03 +0200, Eric Pouech wrote:
>>Apart from the duplication of the signal mechanism, it also introduces
>>races, since we depend on the client to do part of the suspend
>>code. It means the server state will not necessarily match the actual
>>state of the client thread, which could cause trouble. I'm still not
>>convinced we want that in the standard tree.
>looking at VG MLs, it seems that there's already some ongoing work (http://www.goop.org/~jeremy/valgrind/ get to #77) which would provide a better signal handling, so this might be a way to get through that (I didn't test it though)

this patch is providing SIGINFO support and sigcontext availability in a
signal handler. I have independantly implemented the sigcontext functionality needed by WINE;
we have been discussing using this patch instead on the valgrind list...

it doesn't help with this race condition (which I'm pretty convinced already
exists)


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.