Re: Integrating guile-gtk with other event loops

[Owen Taylor <otaylor redhat com>]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Maciej Stachowiak <mstachow@mit.edu> writes:
> 
> > I hope this is an appropriate place for questions about guile-gtk; I
> > know of no more appropriate list.
> 
> It's ok here, I think.  You could also try guile@cygnus.com, depending
> on what kind of problem you have, Gtk or Guile specific.
>  
> > I am trying to figure out a way to integrate guile-gtk's event loop
> > with another event loop, specifically that of scwm.
> 
> That's an important topic.  I wanted to do something about this
> myself, but I haven't got around to it.  I'm especially interested in
> running a event loop in parallel to the normal Guile repl.
> 
> > I can now get guile-gtk to load successfully and create windows, but
> > the ways I've come up with to integrate the event loops all seem
> > hackish; the main problem seems to be that there is a high tradeoff
> > between ease of implementation and correctness. Here are the three
> > approaches I've thought of:
> 
> Do you think that guile-gtk poses special problems compared to a pure
> C approach?  I mean, how would you do it from C?  Guile-gtk is
> supposed to mirror the C API of Gtk+ fairly closely.  The repl might
> be something special, tho.
> 
> > * Add the following:
> > 
> > (lambda () 
> >   (while (not (= 0 (gtk-events-pending)))
> > 	 (gtk-main-iteration)))
> a small amount
> There is 'gtk-update' which does this.
> 
> > * Write a mini-library that provides a function which returns the file
> > descriptor being used for gdk's X connection. Add an input hook to
> > scwm's event loop on this file descriptor which does the same as the
> > above solution.
> 
> That sounds fine to me.

That won't work. GTK+ uses its own timeouts internally, and so 
gtk_events_pending() may suddenly return true when there is
nothing waiting on the X descriptor.
 
> > * Write a dynamically loaded module that provides a hacked version of
> > gtk-main that uses scm_internal_select in place of select; this would
> > allow the gtk event loop and the scwm event loop to peacefully coexist
> > through Guile's cooperative threads.
> 
> I like this one best, provided scm_internal_select is effective, and
> Gtk+ does not have problems with threads (although Guile's threads are
> cooperative, and don't feel comfortable about using them with a
> not-thread safe library, just think of a thread switch occuring during
> a callback, and someday we will have POSIX threads).
> 
> I'm not sure if I'm doing the Guile guys justice here, but:
> scm_internal_select is there, but not all of Guile actually uses it.
> That means that we do not have non-blocking I/O yet.  It's on the
> schedule for 1.3, tho.
> 
> I know there was progress towards thread-safeness in Gtk+.  Is it
> there?

If GTK+ is only called from a single thread, you should not
have to worry about the thread safety of GTK+ in any case.

GTK+-1.1 provides some of thread awareness. (There is a global
lock that the application must obtain before making GTK+ calls).
If the locking calls were made substituable, then this scheme
could probably be extended to 

But, actually, since GTK+ is reentrant around the select(), you don't
really need to go that far. The only sticking point would be the
gdk_threads_wake() call that is needed to wake up the main thread out
of the select() when another thread adds an idle handler; that
isn't enabled unless GDK thinks it is using threads. 

Regards,
                                        Owen