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 debug registers.
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 the situation.
Oh and finally for Mike, it turns out our guess was wrong: SIGSTOP isn't used because it's process-wide on NPTL.
thanks -mike