[Mono-dev] Control-C handler

[Jonathan Pryor]

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
safe.

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?

Thanks,
 - Jon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: us-test-lupus.cs
Type: text/x-csharp
Size: 4294 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080204/bd057f11/attachment.bin