[Mono-dev] Control-C handler

[Jonathan Pryor]

On Wed, 2008-01-09 at 12:33 -0500, Jonathan Pryor wrote:
> Attached are patches to mcs/class/Mono.Posix/Mono.Unix.Native and
> mono/support as an initial implementation of this idea.  It currently
> uses a dedicated Mono.Posix-internal thread to do managed signal
> dispatching (as the ThreadPool is intended for short-lived tasks, and
> I'm not familiar enough with the Timer-related infrastructure to see if
> it would be a good fit).

Attached is an updated patch set which supports both the existing/new
Stdlib.signal() semantics (as the previous patch set did) in which the
signal handler is invoked on an internal helper thread, and adds a new
Mono.Unix.UnixSignal type to permit polling and/or blocking as lupus
originally suggested.

The one thing I don't like (but can't think of a workaround) is the
interaction between UnixSignal and Stdlib.signal(): as currently
implemented, UnixSignal and Stdlib.signal() can't handle the same signal
simultaneously -- if UnixSignal registered to handle e.g. SIGINT, then
Stdlib.signal() will return SIG_ERR, with errno set to EEXIST.

However, the alternate IS possible: UnixSignal can handle e.g. SIGINT if
Stdlib.signal() was previously called to handle it (and will
consequently replace the original Stdlib.signal() handler).  The
"original" Stdlib.signal() handler will be replaced when the UnixSignal
instance is destroyed.

(One workaround I can think of would be for Stdlib.signal() and
UnixSignal to use the same data structures, but I want to keep the
registered_signals array as short as possible to keep down the signal
handler execution time.  Plus one concern: what *should* happen if one
thread creates a UnixSignal instance for SIGINT, then calls
UnixSignal.WaitOne(), then another thread calls
Stdlib.signal(SIGINT,SIG_IGN) while WaitOne() is blocking?

Of course, this could be used as an argument to dump Stdlib.signal()
support entirely, but it needs to stick around to permit setting SIG_IGN
on a given signal.  I suppose Stdlib.signal() could be restricted to
just accepting SIG_IGN, SIG_ERR, and SIG_DFL and error out if any other
delegate instance is passed, so that people use UnixSignal for all
significant signal usage, but I don't like this either as currently each
UnixSignal.WaitOne() call requires a separate pipe, while
Stdlib.signal() uses a single pipe multiplexed across all registered
signals...)

Thoughts?

 - Jon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mono.Posix-v2.diff
Type: text/x-patch
Size: 10835 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080110/b6f2bb1f/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: support-v2.diff
Type: text/x-patch
Size: 5260 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080110/b6f2bb1f/attachment-0001.bin