Re: [gtk-list] Re: thread safe gtk?

[Marius Vollmer <mvo zagadka ping de>]

Owen Taylor <otaylor@gtk.org> writes:

> (One approach which avoids putting threading dependent code into
> GTK+ is to allow the application to supply a replacemnt for
> select())

This would be a good thing for Guile, too.  Guile has support for
threading on the Scheme level by providing its own cooperative
threading engine (qthreads, I think) and having the evaluator
periodically perform a context switch.  There is also support for real
POSIX threads but I'm not sure if it still works.

Now, to avoid blocking on I/O gule is going to have its own version of
select (it's called scm_internal_select) that knows about the coop
threads.  Making Gtk use scm_internal_select instead of select would
make it easy to integrate Gtk into this scenario.

I'm not sure if this would solve the rest of the problems with
threading (the ones you are currently discussing) but the coop threads
are sufficiently well behaved that it shouldn't be too difficult.  For
that, it would be very useful if Gtk could be instructed to use
externally supplied mutices/condition variables.

Anyway, Im excited about having a thread safe Gtk.