Re: External event loop for glib?

[Owen Taylor <otaylor redhat com>]

Antti Huima <huima@ssh.fi> writes:

> On Mon, 29 Mar 1999, Helge Hess 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.
> 
> Hi,
> 
> I originally raised the question about the event loops. Thanks for the
> responses and the discussion that resulted.
> 
> 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...
 
> 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.
 
> 3. Make our event loop use that of glib. (See above.)

This you could do without LGPL problems at all.
 
> 4. Run the GUI in a separate process with its own event loop
>    and communicate with it using some IPC means
> 
> Of these alternatives,
> 
> 1. requires quite lot of work that is not productive.  Moreover, the
> non-existence of glib documentation would make this somewhat guesswork.
> 
> 2. has the GLPL problems as well as the trouble with missing
> documentation.
> 
> 3. has the following problems: (1) glib is not documented well and thus
> transition to use glib event loop is difficult. (2) the exact semantics of
> event loops in the case of callbacks changing the file descriptor
> requests, signal catching etc. can vary. Moreover, before glib is
> rigorously documented telling what the event loop actually does, we cannot
> trust our software to run in the hands of glib.

>  Our event loop captures
> signals and is callback-safe. How can we trust that glib is? Generally, we
> can't trust glib's event loop for security-critical software in its
> current form (SSH Communications Security Inc. develops high-quality
> computer security software).

Since security is a pretty broad term, I'm not sure how 
respond. 

I think GLib is a pretty solid library for using in security
critical programs, but as always, caveat emptor.

(GTK+, as being much more complex, I would consider more of
a risk. For one thing, you should definitely not use GTK+
in a setuid program.)

The event loop, though, seems like a pretty safe part, in
general, since it does not make any attempt to do IO for
you - but simply handles notification when IO is ready.

So, it isn't going to introduce buffer overflows, etc.

> 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...

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...

Regards,
                                        Owen