[Mono-dev] Control-C handler

[Avery Pennarun]

On 02/01/2008, Robert Jordan <robertj at gmx.net> wrote:
> Avery Pennarun wrote:
> > Surely there must be *some* way to handle signals from inside a mono
> > app?  This seems like a huge omission.  Even perl can do it!
> > (http://search.cpan.org/~lbaxter/Sys-SigAction-0.10/lib/Sys/SigAction.pm)
>
> Well, perl's standard signal handlers suffer from the same limitations
> like mono's and the new "deferred" signal handlers are just a lame
> compromise.

All signal handlers in any language suffer from the same limitations:
there's no guarantee that the mainline is in a safe state at the time
the signal handler is called.  That means the set of "safe" things you
can do in a signal handler is extremely limited.  In C, this basically
restricts you to direct syscalls (ie. manpages section 2, not section
3) and setting variables.  Generally this is enough, leading to two
safe options in C:

1) Set a (volatile) variable in the signal handler and check it from
the mainline.

2) write() to a pipe during a signal, and poll the read side of the
pipe in the mainline so that it wakes up.  This is safe in a signal
handler because write() is a syscall.

and one unfortunately all-too-common unsafe option:

3) Just ignore the fact that it might not work and do whatever you
want in the signal handler anyhow.  It'll work 99% of the time.

It seems like if mono could guarantee certain things, such as the fact
that an already-JITted function will never be thrown away, that a safe
implementation of #1 would be possible as Jonathan Pryor posted above.
 Does mono make that guarantee?  Will it continue to do so?

Currently implementation #2 is probably impossible (or unsafe) in mono
since the socket code is probably much more complex than a syscall and
may still be in an unsafe state.  Perl has a similar problem, which is
why the "deferred" signal handlers were created.

Option #3 is probably not 99% safe in mono, which has more runtime
state outside the kernel than a C program would.

What makes the perl ones a "lame compromise" in your opinion?

How does Microsoft's .Net handle Windows-style "signals", such as
memory-access errors?  Could we use a similar method in mono?

Have fun,

Avery