Re: External event loop for glib?

[Owen Taylor <otaylor redhat com>]

Per Hedbor <per@idonex.se> writes:

> I have already looked at ways to use glibs main-loop in pike (when
> using GTK).
> 
> It's not easy. Not even close to easy. Glibs main-loop might have
> improved since I looked at it last time, though (it has been about
> three weeks).
> 
> Pikes main loop is actually more 'threaded' than glibs, you can remove
> fds (and handles, under NT) from it while it's waiting for events, and
> while it's calling call-backs, without breaking anything. 
>
> I failed to do that with glib. 

I'm not sure if you are talking about actual OS threads or not.

Without threads, you should be able to remove IO watches
fd's at any point without difficulty.

The same thing holds true in theory when running threaded,
except that there is a known bug which will cause difficulties.
(The code mistakenly assumes that the set of FD's won't
change across poll())

But that is a bug that simply needs to be fixed - the fix
is not that hard to implement, though a bit messy.
(If there are any problems at all with the reentrancy
with GLib's main loop, please report them as bugs
when you run in to them)

> It also handles signals (which is not all that easy to do portably)
> and reaping of children with call-backs (sigchild behaves drastically
> different under Linux and Solaris, as an example. Under Linux you get
> one signal / thread you have, while you only get one signal under
> Solaris).
> 
> Most of the stuff above can be fixed using extra FDs, though
> ("internal" pipes).

It is easy to add signal and child-reaping event
using the GSource API that GLib exports. In fact Tim
has some code for this that will probably get added
to GTK+ (he wanted to rush it in before 1.2 actually, but...)

> It also handles has one call-back for oob read, one for oob write, one
> for write, one for read and one for close events. That could be
> simulated with a simple wrapper, though.

On systems that support poll() natively, GLib will
provide close events. (GIOCondition/G_IO_HUP). 

On systems without a native poll(), you'll get the standard 
G_IO_READ => zero length read.

There are no predefined G_IO_* constants for POLLRDBAND
and POLLWRBAND (being of somewhat uncertain portability),
but actually, the GLib code intentionally passes through
whatever flags you pass to g_io_add_watch() to poll()
so if you have POLLRDBAND and POLLWRBAND, you can use them.

Simulating this stuff on systems without a native poll()
seems rather difficult. Does pike do it?

Anyways, it sounds like Pike has a rather nice 
main loop; but it sounds like the main advantage it
has over GLib's is that it might be a bit more debugged
on threaded systems. 

Regards,
                                        Owen