Re: Unix signals in GLib

["Freddie Unpenstein" <fredderic excite com>]

From: "Andy Wingo", Date: 30/04/2010 19:01

> On Fri 30 Apr 2010 10:23, Xavier Bestel <xavier bestel free fr>; writes:
>> 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.
>> Can't you just signal your mainloop to quit from the signal handler, and
>> do the heavyweight work from there ?
>
> g_main_context_wakeup () is not signal-safe.
> The correct thing to do is to make a socketpair, and write on it from
> the signal handler, and tie the read side to a GSource.

The "unix" way of signalling termination and some other system-wise non-GUI stuff is through unix signals, and is unix-specific.  Also, very much non-trivial.

But doesn't Windows have a similar capacity?  How does Windows signal an application to close, if it doesn't have a window?

It seems to me that there should be some kind of standardised "GApplicationSignal" which gathers all these together in one place.  SIGTERM would map to G_APPLICATION_SIGNAL_CLOSE, as would the Windows equivelant through whatever mechanism it uses.

GApplicationSignal would do its best to allow these signals to be handled as consistently and flexably as possible, despite the unique characteristics of the various operating systems.  And since it's already doing its thing in an OS-specific way, it would also allow the application to query which signals/capabilities are available, and the header would emit appropriate Glib-ized defines to make the inevitable OS-specific code simpler and more consistent itself.

Such a mechanism could also accept the same kinds of messages sent through newer channels in the future, and what-not, and funnel them all through that single cleaner interface.


I'm sure I've heard of this sort of thing being bounced aroud Glib/GTK before somewhere...  In the recent GApplication discussions, this would sit in pretty nicely; this could well be implemented independantly, but included within the broader GApplication namespace.


Fredderic