[Mono-dev] Need help with signal handlers.

Paolo Molaro lupus at ximian.com
Sat Aug 20 09:40:54 EDT 2005

On 08/19/05 Jonathan Pryor wrote:
> The larger problem is one of reentrancy: Mono is not reentrant, and
> neither is the P/Invoke layer.

Almost nothing is signal safe in libc, so the issue is not just Mono.
Saying that the P/Invoke layer is not reentrant is not precise and
not really relevant.

> Reentrancy is similar to thread safety, but different: when a signal
> occurs, a (potentially random) process thread is "hijacked", a new stack
> frame is added (or worse, the current stack frame is re-used), and the

Ugh, no, that is not what happens, the current stack frame is not
touched at all.

> The only safe thing you can do is call other reentrant functions, and

This is correct.

> In short, signal handlers are a whole new world of pain.  Managed code

As is this.

> only makes things worse, since the entire P/Invoke layer isn't
> reentrant, so you risk many unknowns just trying to use a managed
> delegate as a signal handler, never mind doing anything complicated from
> the handler.

This is not.

> Thus, the advice: assuming you risk using a signal handler in managed
> code, all you can do from managed code is modify a variable.  That's it.
> Anything else, *especially* a P/Invoke call, is suspect.

Changing a var may also be incorrect, if the signal handler was not
already compiled. So it's possible to have more complex handlers, even
ones that use P/Invoke, but they must be already compiled by the jit
and they may not call any non signal-safe function either directly or
through the runtime (so if you call methods in mono, you need to know
what they end up doing). In general people should stay away from signal
handlers and implement them in C so that when they use signal-unsafe
functions they won't blame mono for their program blowing up:-)


lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better

More information about the Mono-devel-list mailing list