[Mono-dev] Control-C handler

[pablosantosluac]

Is it integrated on trunk?



----- Original Message ----- 
From: "Jonathan Pryor" <jonpryor at vt.edu>
To: "Paolo Molaro" <lupus at ximian.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Thursday, January 10, 2008 5:52 PM
Subject: Re: [Mono-dev] Control-C handler


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


--------------------------------------------------------------------------------


> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>