[Mono-dev] Control-C handler
jonpryor at vt.edu
Mon Feb 4 16:27:15 EST 2008
On Mon, 2008-02-04 at 12:38 +0100, Paolo Molaro wrote:
> On 01/28/08 Jonathan Pryor wrote:
> You should write a test case to stress-test this code and see if it
> behaves correctly under a storm of signals, say at least 100k signals.
> You should check that no signal was lost. Repeat the same while one
> thread adds/removes handlers. Repeat with two threads doing a WaitAny()
> and using more than one signal.
See attached test program. It works if all Stdlib.raise() calls are
from the same thread.
> Repeat with two threads calling kill()
> to send the signal. Do all of this on a SMP box.
...and it fails if I use Syscall.kill() to send the signal, or I use
multiple threads to call Stdlib.raise(). (Stdlib.raise() invocation is
synchronous, hence it works if only one thread calls it.)
When using Syscall.kill() or Stdlib.raise() concurrently from multiple
threads, I lose signals, presumably because the signal handler is being
invoked simultaneously (Core2 Duo CPU) and the handler isn't thread
So now I'm at a quandry: I can't make the signal handler thread-safe as
Pthreads functions aren't signal-safe, yet we're requiring the ability
to invoke the signal handler from multiple threads.
So obviously things go "bad".
The only fix I can think of is to not use "++h->count" within the signal
handler, but to instead use an atomic function like g_atomic_int_inc(),
but that doesn't solve the problem either -- signals are still missed.
(I'm frankly surprised that g_atomic_int_inc() isn't fixing this, as two
threads trying to increment the count is the only reason I can think of
for why signals would be missed.)
Any suggestions on a solution?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4294 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080204/bd057f11/attachment.bin
More information about the Mono-devel-list