[Mono-dev] Control-C handler

[Jonathan Pryor]

On Tue, 2008-01-08 at 22:02 -0500, Jonathan Pryor wrote:
> Thank you for the background on why signal handlers can't be made to
> work with the current Stdlib.signal implementation.
> 
> However...
> I don't see why we need a new API to support this.  It seems that we
> could retrofit the existing Stdlib.signal() API to use the
> implementation you described, with one difference: a runtime internal
> thread could be used to block on the internal pipe, and when the pipe is
> readable it could dispatch the appropriate signal via delegate
> registered with Stdlib.signal().  No polling, and no new public API
> would be required.
> 
> The one thing I'm not sure about is which thread should wait on the
> pipe.  Would a dedicated Mono.Posix-internal thread be more appropriate,
> or would one of the existing threads be beter (e.g. a ThreadPool thread,
> or a Timer-related thread, or...).

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

Thoughts?

 - Jon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mono.Unix.Native.diff
Type: text/x-patch
Size: 3717 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080109/cd9c4d3d/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: support.diff
Type: text/x-patch
Size: 2374 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080109/cd9c4d3d/attachment-0001.bin