Eric Pouech ([EMAIL PROTECTED]) wrote: > ...
But, the address we get in GetThreadContext is the one from where the thread waits on the server (hence the 0xffffe410 address), not the address it was suspended from (as it's supposed to be)
I don't think it will be easy to fix.
Possible ideas:
...
- storing context in server while entering USR1 signal handler (to be done without races, which will require some more work, as the server doesn't synchronize with the USR1 handler)
This one seems most natural. Maybe the server should wait for the context to be stored before returning from SuspendThread. I bet on Windows, the target thread is really suspended before SuspendThread returns, and this would ensure that behavior.
Maybe if we do this right, we can get rid of the racy looking loop at the top of test_SuspendThread() in dlls/kernel/tests/thread.c ... or is that loop needed on Windows, too? - Dan
-- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change
