Re: Moving main loop to GLib.

[Marius Vollmer <mvo zagadka ping de>]

Owen Taylor <otaylor@redhat.com> writes:

> Unix certainly has events that don't fit well into the poll() / select()
> model. The two most interesting examples are SIGCHILD and signalling
> between threads. Unfortunately, I don't know of _any_ good way
> of handling these together with FDs, except for using fork()
> or extra threads and communicating with the main thread via
> pipes.

Some time ago I came across an interesting trick for fitting
asynchronous signals reliably into a select/poll loop.  You just make
a pipe and include it in the read-set of your select.  In the signal
handler, you do nothing but write a byte to this pipe.  The point was
to make this kind of thing more reliable than a naive approach would
be (due to some strangeness in the Unix signal model that I don't know
about), so I might have missed some crucial details.  I can try to
find the original info, when there's interest.

I think that GLib should also provide a central point for
child-exit-status notification.  I also think that this can be nicely
layered on top of the proposed event loop, so its not necessary to
include it right now.