[Mono-dev] Control-C handler

[Avery Pennarun]

On 08/01/2008, Jonathan Pryor <jonpryor at vt.edu> wrote:
> 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.

It seems to me that lupus's suggestion is more general than this.  In
other words, you could implement your desired API above on top of his
without any extra overhead (ie. the overhead is inherent to the
interface), while you couldn't implement his on top of yours without
doing a lot of unnecessary work (ie. bouncing into a thread and then
back again).

Since mono's signal API is already (presumably) non-standard, it
should be harmless to correct it by introducing a new nonstandard one
that works properly.

Note that polling a variable is a fine way to handle signals in many C
programs.  I often write mainloops of the form "while (!want_to_die)",
where want_to_die is set by my SIGTERM/SIGINT/etc handler.  Involving
a thread for this purpose would be overkill.  While this method does
count as "polling", it is syscall-free polling and only happens at the
places where you would want to shut down cleanly anyway.

This reminds me, though: what happens to things like socket
read/write/connect system calls in mono when a signal comes in?  In C,
they get interrupted and return EINTR/EAGAIN, which is why you pop
back to the mainloop and get a chance to poll your signal variable.
But if the .Net API requires that there's no EAGAIN-style return code
for file operations, then they'll have to silently retry and a simple
signal variable won't work in any real-life program.

Have fun,

Avery