Re-examining SetThreadContext

[Mike Hearn]

Hi Alexandre,

A user recently reported another app that doesn't work due to Armadillo
copy protection. This scheme requires SetThreadContext/GetThreadContext to
work properly and currently they do not.

These two functions require the thread to be suspended, therefore they
always return a bogus context (blocking on a wineserver wait pipe).

I wrote a patch for this a while ago:

http://navi.cx/svn/misc/trunk/winekb/patches/thread-context.patch

However you felt it had races in it. There were two possible races I could
see:

- The race between suspending the thread and the sigcontext being uploaded.
  This was not a problem with my patch as Get/SetThreadContext loop.

- A race where you can call SuspendThread again before the SIGUSR1 handler
  has completed. I believe this was the sticking point last time, no? But
  I can't see how this can happen because SIGUSR1 is blocked while it's
  being handled.

So in the following sequence:

PROCESS A: SuspendThread()
PROCESS A: GetThreadContext()
PROCESS B: SIGUSR1
PROCESS B: upload sigcontext
PROCESS B: block
PROCESS A: GetThreadContext() returns
PROCESS A: ResumeThread
PROCESS B: unblock, download sigcontext, restore, finish

I do not see where the races are. Could you please re-examine this patch
and let me know if there are any more problems with it?

Dealing with the set/thread context operations in SIGUSR1 makes sense
because they are only allowed when the target thread is suspended.

thanks -mike