Re: External event loop for glib?

[Owen Taylor <otaylor redhat com>]

Helge Hess <hh@mdlink.de> writes:

> Kenneth Albanowski wrote:
> > On 28 Mar 1999, Owen Taylor wrote:
> > 
> > Let me add on to Owen's comments by saying that we (or as least I) would
> > like to see the Gtk (GLib, really) main loop become the standard
> > "universal" main loop. So far everybody has rolled their own, and it makes
> > it nearly impossible to blend different systems together (witness the
> > current problems :-). If this means fixing all sorts of bugs, and
> > borrowing the neat features from every other main loop implementation,
> > then so be it.
> 
> This might be possible if gtk+/glib would be a standard library
> available on every system. Unfortuntatly this is not the case. As
> someone who would like to use gtk+ as a GUI toolkit, I'm somewhat
> annoyed by the requirement for the runloop.

GLib is, by definition, a library available on every system
where one wants to use GTK+.

It also is quite conceptually portable to platforms that 
don't have GTK+.

If you are porting GLib to a system substantially different
from Unix then it is expected that you will need to reimplement 
the GLib main loop to some extent or another.

> Eg, I'm using the Objective-C Foundation library which is much like
> glib. This library runs on a variety of systems, including Windows and
> most Unixes. There are various GUI toolkits written in ObjC that run on
> top of the Foundation library and it is IMHO not acceptable to change
> the Foundation just for gtk+.
> 
> Personally I do not understand what's so difficult about supporting
> external eventloops with gtk+ (it's not even about accessing gmainloop
> !). There just need to be some entrance functions to setup/teardown gtk+
> and some hooks for adding events. Eg. gtk+ could use function callbacks
> for doing runloop stuff, those could be reassigned by other runloops.

First, the setup/teardown for GTK+ is 100% independent from
the GLib main loop. (Well, sort of, the setup for GDK does register
hook additional event into the GLib main loop).

There are a number of reasons why the GLib main loop cannot
be simply expressed in terms of "Add a timeout", "add a fd watcher"
"start the main loop" callback hooks. I think I've mentioned
them before, but to reiterate:

 - GLib provides a 100% recursive main loop. Most main loops don't.

 - GLib includes a concept of prioritized sources. To implement
   this properly requires that the set of fd's (or equivalent)
   that is checked at each pass of the main loop varies.

Most likely, you could get GTK+ working with a main loop that
isn't that good, and doesn't properly implement all this, 
but that would just be a pale shadow of the real GLib main
loop.

These makes it quite difficult to make GTK+ a client of an
external event loop. 
 
> > Moreover, any comments leading towards a better main loop -- one that can
> > take over more resposibilities from other packages, or even one that can
> > easily be subsumed by or cooperate with other implementations -- would be
> > welcome.
> 
> Well, for example the Foundation NSRunLoop class supports so called
> modes. Take a look at
> 
> http://developer.apple.com/techpubs/macosxserver/System/Library/Frameworks/Foundation.framework/Versions/C/Resources/English.lproj/Documentation/Reference/ObjC_classic/Classes/NSRunLoop.html

I must admit that I don't understand the concept of modes
(or if I do, they seem like an utterly broken concept ;-)
So I'm not quite sure what you are getting at.

To take some guesses

 1) GLib can't handle Mach ports and such from Mac OSX.
    See my above comment about porting GLib.

 2) You could't implement NSRunLoop on top of the GLib main
    loop under Unix. 

    True, mostly because the GLib main loop doesn't allow
    having separate main loops runnning in different threads.
    (That actually would be a nice things to add in the
    future for Lib... it isn't very interesting for GUI
    apps, but would be nice if you were writing a multithreaded
    server using GLib)

    If you were willing to much about in the the guts, you probably
    could make the NSRunLoop in the main thread use the 
    GLib main loop (it could register itself as another
    GSource - which would allow about any semantics you
    wanted), and the other run loops work directly in terms
    of select() or poll().

 3) You can't implement the GLib main loop on top of
    NSRunLoop under Unix)

    You certainly could (assumming that there was a decent
    NSPort derivative to handle Unix fds). A poll function
    (g_main_set_poll_func()) could be implemented in terms
    of runUntilDate.

    This wouldn't be especially efficient, but it would
    work.

    If I was modifiying GLib to make such a thing more efficient,
    I would probably think about replacing the poll_func()
    with a poll object with operations like add_poll()
    and remove_poll(). But I'm not sure how you would
    deal with the fact that to properly implement priority
    you have to check all fd's at a certain priority
    level before you dispatch the callbacks.

Regards,
                                        Owen