Re: External event loop for glib?

[Kenneth Albanowski <kjahds kjahds com>]

On 29 Mar 1999, Owen Taylor wrote:

> Antti Huima <huima@ssh.fi> writes:
> 
> > As for me, the possible alternatives seem to be:
> > 
> > 1. Reimplement glib totally (avoiding certain GLPL problems)
> 
> I would hope that you wouldn't do that...

However, the idea might merit some consideration. Note that GLib is your
basic algorithm library, and most advanced development environments are
going to have an equivalent set (ObjectiveC, Perl, etc.) It's conceivable
that it would be more efficient (in terms of code-space, if nothing else) 
to "port" GLib to the native algorithm library, assuming that it is
feasible.

(All of the other layers of Gtk+ seem to have would up flexible in the
porting department, so why not GLib?)

I'm thinking of this sort of thing because I've seen it go the other way
 -- in some places, it would be handy if the Perl/Gtk binding could refer
to GLib objects (lists, hashes, etc.) through Perl proxy objects. (Which
is something that Perl needs to worry about, not GLib.) 

> > 2. Patch glib to use our event loop (slight GLPL problems as the
> >    patches must be applicable to newer versions of glib, I think)
> 
> Well, actually, if you patched GLib to use your event loop,
> the LGPL would probably require that you make the sources
> to your event loop available under something like the LGPL.

No, if their event loop isn't GPL or LGPL, there is no requirement for the
source of their code to be available. (Just like GLib can invoke libc
routines that may not be Open Source.) Or so I think -- IANAL.

> > Therefore it seems that I'm inclined to choose 4. While requiring some
> > extra work for IPC, I avoid
> > 
> > - the problems caused by the event loop differences
> > - the problems of using one more external library in security-critical
> >   software
> > - the problems of Xlib exit(3)ing when X connection drops or something
> >   other stupid happens
> > 
> > *IF* GTK allowed one to use its own event loop (which I think wouldn't
> > require that much effort) then perhaps my choice could be different. Of
> > the current alternatives, this is perhaps the best one.
> 
> Without knowing more about the details of your application,
> it's a little hard to say, but I'd say, in general, that that
> sounds reasonable. I'm sure that if I made up a quote from
> somebody famous saying that "security is best achieved by
> breaking up your software into small, well-defined pieces",
> nobody would object too much...

Owen, do you have any technical opinions on allowing Gtk (or GLib, rather) 
to be hosted by a foreign main loop? If it is technically feasible, and if
GLib were capable of implementing/emulating all the facilities that the
outer loop isn't capable of (like precedence), this would seem to be a
valuable solution, and would still provide the benefits of the GLib main
loop. 

I'm thinking of one of the main-loop jobs I did (merging the Tcl, Tk and
the GNU Readline 2.0 main loops), in which the only feasible solution was
a kludge that subverted Readline by replacing its internal getchar/getline
routines with code that iterated over the Tcl main loop until stdin was
readable (as determined by the Tcl fd watcher), as which point the
Readline code invoked Tcl's buffered getchar/getline, which in turn
reinvoked a nested main loop, this time within Tcl. The net result is an
enourmous kludge, but completely functional, and I'd love to see GLib be
as -- or more -- flexible.

(Which probably means reimplementing stdio somewhere along the line,
unfortunately. Everybody seems to reinvent _that_ one, too. Unfortunately
you can't get proper fd watching of buffered descriptors if you don't
implement your own stdio.) 

> As a side benefit, you may get better interactive performance
> if any computationally intensive pieces are split off 
> from the GUI. The GLib main loop is nice enough that 
> doing IPC over pipes, etc, is usually pretty easy...

Agreed, but also more complex, and taking more resources. X already has
enough sockets bouncing things around... 

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)