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.
