Re: Unix signals in GLib

[Owen Taylor <otaylor redhat com>]

On Fri, 2010-04-30 at 09:18 +0100, Richard Hughes wrote:
> I'm writing for comments. Making my daemons (upower, PackageKit, etc)
> quit nicely after receiving SIGTERM or SIGINT is _really_ hard to do
> correctly. The fact that I can only do a few things (write, etc) in
> the signal handler makes otherwise quite nice GLib code very quickly
> descend into l33t UNIX #ifdef code which is quite unportable and
> really hard to get right.
> 
> Would there be any interest in providing these features in Glib? Some
> work appears to have been done already here
> http://www.knitter.ch/src/gunixsignal/ although would obviously need a
> lot of work before being even close to proposing. I appreciate this is
> UNIX only, but I'm sure for other OS's (WIN32) we can just do nothing
> for these functions. Comments?

It would be nice to have this functionality. The caveat is that it's
also tricky - we were originally planning to do GChildWatch as a more
generic mechanism but we gave up on that and found making it work just
for one signal tricky enough.

Some things that I remember as difficult:

 * Signals are a process-global resource. What GLib needs to do
   to reliably catch signals may depend very much on how the signal
   is configured. So, either you have to say that applications can't
   call signal(), sigaction(), etc, on their own at all, or you have
   to give very detailed instructions about exactly what they do.

 * The are race conditions if you get signals just as you are setting
   things up. They were crucial for SIGCHLD,  and solvable because of
   the known interaction with waitpid(), but this was one of the big
   reasons we had trouble basing GChildWatch on a more generic
   functionality. This may be less of a problem for TERM/INT/etc.

 * Interaction between signals and threads is complex. GChildWatch
   works very differently depending on whether threads are enabled 
   or not.

- Owen