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.