New subject: signaling unix threads

8 Nov 2004


      Mike Hearn wrote:
...
I quite liked Michaels idea of the RT signals. Is there some reason we
can't use them?
I didn't see Michael's proposal.  Can you point to it?
Now, I don't pretend to understand the issues here, but reading your patch,
http://www.winehq.org/hypermail/wine-patches/2004/11/att-0041/01-patch__char...
I see the comment
      * ... there is a race with SuspendThread(): the app
      * can call SuspendThread() then GetThreadContext() whilst the
      * target is processing SIGUSR1 but before it's been able to
      * override the thread context, ie the context returned would be
      * meaningless to the app (internals of Wine itself).
I understand similar races are present in real Windows, too.
e.g. http://blogs.msdn.com/cbrumme/archive/2003/08/20/51504.aspx says
"[with SuspendThread,] there’s a significant risk of leaving a
thread suspended at a “bad” spot.  If you call SuspendThread
while a thread is inside the OS heap lock, you better not try
to allocate or free from that same heap.  In a similar fashion,
if you call SuspendThread while a thread holds the OS loader lock
(e.g. while the thread is executing inside DllMain) then you
better not call LoadLibrary, GetProcAddress, GetModuleHandle,
or any of the other OS services that require that same lock.
Even worse, if you call SuspendThread on a thread that is in
the middle of exception dispatching inside the kernel, a
subsequent GetThreadContext or SetThreadContext can actually
produce a blend of the register state at the point of the
suspension and the register state that was captured when
the exception was triggered.  If we attempt to modify a
thread’s context (perhaps bashing the EIP – on X86 – to
redirect the thread’s execution to somewhere it will
synchronize with the GC or other managed suspension),
our update to EIP might quietly get lost."
I guess we just need to have races no worse than in Windows :-)
About RT signals -
I would tread carefully here.  RT signals are a precious resource.
The queue is not very deep, and it's *per system* on Linux IIRC.
When I used RT signals for I/O, they overflowed the queue all the time --
and if any program in the system is doing that, it affects your
program, since the queue is shared.
- Dan
-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

Re: signaling unix threads