mike at navi.cx
Thu Nov 4 14:02:24 CST 2004
On Thu, 04 Nov 2004 14:11:08 +0000, Mike Hearn wrote:
> Well, don't leave me in suspense, show me where they are! :)
I talked on IRC to Alexandre about this. The first race he was thinking of
is not a problem with this patch as Get/SetThreadContext loop until the
context is uploaded. The second race is setting the context after the
suspend context has been released but before SIGUSR2 returns.
Long term the plan is to use SIGUSR2 to implement SetThreadContext, with
SIGUSR1 uploading the sigcontext to the server for GetThreadContext like
in the patch.
That requires modifying DOSVM so it doesn't use SIGUSR2 (or figuring out
how to overload SIGUSR2).
Alexandre isn't going to apply the patch for now, on the grounds that it
needs to be done properly and the current code does at least work for
This does leave the question of OpenGL/D3D thread affinity open, the plan
was to use a signal for that but we only have 2!
If anybody wants to run with this, be my guest. I won't be working on it
anytime soon. It might be worth adding a comment to the source explaining
Oh and finally for Mike, it turns out our guess was wrong:
SIGSTOP isn't used because it's process-wide on NPTL.
More information about the wine-devel