mh at codeweavers.com
Sun Feb 6 11:17:24 CST 2005
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:
However you felt it had races in it. There were two possible races I could
- 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
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.
More information about the wine-devel