Eric Pouech (pouech-eric@wanadoo.fr) 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
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?
I think it's needed. The loop is only here to wait for the child to call actually SuspendThread. So, it's just about being sure that the child is able to call SuspendThread in a decent time (the issue being what value should we put for a 'decent' time). A+
-
Dan Kegel -
Eric Pouech