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