Re: Integrating guile-gtk with other event loops

[Owen Taylor <otaylor redhat com>]

[ 
  I'm replying to gtk-list, but this really should be on
  gtk-devel-list, instead, I think.
]

The way multiple event loops are currently handled, is that one
library (typically the GUI toolkit) provides the main loop, and the
rest of libraries subscribe to it.

(This is done, typically, by letting the user provide functions to be
called when input handlers and timeout functions need to be added.)

The problem with this occurs when something other than the GUI toolkit
needs to run the event loop itself, or, occasionally, when you need
to have multiple GUI toolkits running at once. The former case
is the problem here, in that guile() needs to use its own select().

Could GTK+ be made to use somebody elses event loop?  GTK+ demands a
lot from its event loop:

 - Prioritized idle functions
 - Full recursivity

And additionally, event handling from X does not fit into a simple
select-on-file-descriptor model. X will read multiple events from
server into its buffers at once.  So the select() cannot be re-entered
until XPending() returns false.

If X events were done from a input handler, then the input handler
would have to process the entire queue at once, which could lead to
starvation of timeouts in some circumstances.


So I don't think that making GTK+ being able to subscribe in
the current standard in event loops works. 

There are three solutions I can think of three solutions 
to the guile problem:

 1) (approx. what Marius suggested). Externalize the select()
    from the rest of the event loop, so the event loop optionally
    instead of calling select() returns to the caller with 
    a list of fd's, and a timeout value.

 2) (A variant of the above). gdk_set_select() - the application
    provides a replacement that will be used when necessary.
    [ Actually, gdk_set_poll() might be better; a select() based
    emulation of the parts of poll() that are needed can be provided 
    for systems without poll() ]
    
 3) Create a more general event-source abstraction that GTK+ 
    can either provide or subscribe to. Essentially, you would
    register an event source with three functions:

     - Do you you events currently?
     - How will I know when you have events? (basically, timeout,
       poll, or input handlers)
     - Process your events.

    The problem with the idea of somebody else supplying this
    is that, as above, most existing event loops just aren't
    up to the needs of GTK+.

My feeling is that  guile's user-threads should be seen
as sort of a special case - almost anything else could use
GTK's mainloop, so gdk_set_poll() would be the easy thing 
to do.

Regarsd,
                                        Owen