[Mono-list] Question on unix signal handling

[Jonathan Pryor]

On Jan 17, 2013, at 11:02 AM, mickeyf <mickey at thesweetoasis.com> wrote:
> I see   in this documentation:
> <http://oddacon.hopto.org:8181/1.1/handlers/monodoc.ashx?link=T%3AMono.Unix.UnixSignal>   
> 
> "In a multi-threaded program, a thread is selected at random among the threads that can handle the signal, and that thread is hijacked to run the signal"
> 
> I understand that that is referring to _unmanaged_ *nix code, not Mono.

Mono Threads are POSIX threads, which are native threads, so that is equally true for managed code. Any thread in the process can be "hijacked" by the kernel to execute signal handlers, and care must be taken to only call signal-safe functions from within a signal handler.

This was why Stdlib.signal() was deprecated: it's not possible for managed code to _only_ call signal-safe functions, as the native->managed transition itself isn't signal safe.

This is also why UnixSignal is _not_ like signal(2). It's a flag that gets "set" when a signal is raised, nothing more.

> So, I'm thinking of using code based on height8's (only 2 year old) blog post :  here <http://www.height8.com/?unixsignal_mono>  
...
> If I have a Mono application with an arbitrary number of threads, can I use this approach to make sure that any signal is properly caught and handled by a single method?

Without dropping down to C and using sigaction(2), there is no way of restricting which thread will execute a signal handler. UnixSignal provides no facility to do that.

> That is, will any signals that are raised be seen only by my signal handler, and ignored by everything else?

As stated above, a UnixSignal represents a flag ("has the signal been raised?"). _You_ aren't providing a signal handler, so there is no signal handler of yours to execute.

> If my Mono app is using unmanaged libraries, I presumably have to ensure that the library code also either ignores any signals or handles them in a sensible way. (Using signal(2), or SIGACTION(2) ?)

Signals are like The Highlander: There Can Be Only One (signal handler for a particular signal).

Some programs and libraries will have special ways to "forward" signal invocation (e.g. mono_set_signal_chaining ()), but that is not common practice afaict. Thus, yes, you would need to somehow ensure that the union of all libraries your app uses doesn't have an overlap in handled signals, e.g. you can't have multiple libraries have their signal handlers raised for the SIGWINCH signal; there can be only one SIGWINCH handler, period.

> What I'm ultimately aiming at is that I can 
> 
> a) make sure that I can shut down my application cleanly and completely by sending it a signal (ctrl-C from the keyboard for example), and that 
> 
> b) it does not get tripped up by signals that may originate from other processes other than a system shut down, an intentional "kill", etc.

That should be doable.

 - Jon