Re: External event loop for glib?

[Antti Huima <huima ssh fi>]

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)

2. Patch glib to use our event loop (slight GLPL problems as the
   patches must be applicable to newer versions of glib, I think)

3. Make our event loop use that of glib. (See above.)

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

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.

I'm still interested to hear any comments about this.

-- 
Antti Huima
SSH Communications Security Oy