Re: [gtk-list] Re: Integrating guile-gtk with other event loops

[Maciej Stachowiak <mstachow mit edu>]

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 think this is more gtk-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.
> 

Well, The first two solutions I mentioned below could be done quite
similarly in pure C. The only thing that I think is guile-specific 


> > * Add the following:
> > 
> > (lambda () 
> >   (while (not (= 0 (gtk-events-pending)))
> > 	 (gtk-main-iteration)))
> 
> There is 'gtk-update' which does this.
> 

I didn't know about that, thanks.

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

The problem I see with this is approach is that it would break gtk's
input, timeout and idle handlers, so running externally developed
guile-gtk code in scwm might have problems

> > * 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 think the way things are set up, a thread switch could only possibly
happen inside a callback (if the callback tries to do I/O that blocks,
or explictly yields). I am not sure if that would have negative
effects on Gtk or not. I do know that the current Guile-Tk interface
uses scm_internal_select to run the repl in parallel with the Tk event
loop, so it seems that scm_internal_select is effective for this
purpose, and that the possibility of thread switches during a callback
is not considered to be that bad (I don't think Tk is thread-safe in
general).


The only problem I see with this approach is that it essentially
requires cutting and pasting all of the code to gtk_main and making
small changes, thus making guile-gtk more tighly linked to a specific
version of Gtk. However, depending on the structure of the code, it
may be that gtk_main really does all of it's work in other functions,
in which case this shouldn't be too bad. I will take a look.


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

Guile doesn't use non-blocking I/O everywhere yet, but it uses is in
most places. In particular, it will work with Guile's select and with
any I/O that is done a character at a time (which is not as big a
limitation as it sounds, most of Guile's current I/O primitives)

However, the most relevant thing to me is that if I make the scwm
event loop use scm_internal_select instead of select

> I know there was progress towards thread-safeness in Gtk+.  Is it
> there?
> 

There has definitely been work on it in the 1.1 tree, however, I am
not sure if it is completely transparent to the user, or if the mutual
exclusion system it uses could conveniently be made to work with
Guile's cooperative threads. 

One possibility is to actually make the guile-gtk wrapper use a guile
mutex to wrap any gtk calls it does when guile-gtk is given some
appropriate configure-time option (perhaps --with-threads to match
guile).


> > Which is best? I think if the last solution is considered useful, it
> > may be worthwhile to provide it in guile-gtk itself so that other apps
> > that have their own event loops can use guile-gtk transparently.
> 
> Yep.  I would be very happy if you could integrate it.
> 

I will let you know about any progress on this front then.