-*- outline -*-

* A few notes on threads and guile-gobject

There are a number of issues to address within guile-gobject before
threading works properly. This document is an initial attempt to
describe the problem before working on a solution.

** Before beginning, a caveat

My knowledge of guile internals is sketchy at best -- if you happen to
notice some errors here do let me know.

** Fact 1: The guile interpreter is single-threaded (at the moment)

It seems that garbage collection is the only non-reentrant part of
guile's API. There are some comments in __scm.h that lead one to believe
that proper multithreading is coming, but the comments are 5 years old
at this writing:

/* Classification of critical sections
 *
 * When Guile moves to POSIX threads, it won't be possible to prevent
 * context switching.  In fact, the whole idea of context switching is
 * bogus if threads are run by different processors.  Therefore, we
 * must ultimately eliminate all critical sections or enforce them by
 * use of mutecis.
 *
 * All instances of SCM_DEFER_INTS and SCM_ALLOW_INTS should therefore
 * be classified and replaced by one of the delimiters below.  If you
 * understand what this is all about, I'd like to encourage you to
 * help with this task.  The set of classes below must of course be
 * incrementally augmented.
 *
 * MDJ 980419 <djurfeldt@nada.kth.se>
 */

There are a few SCM_DEFER_INTS scattered hither and yon in the code, but
because the only thing that relies on them is the signal-handling code
it's not clear to me how much more work it might take to get pthread
support added.

This problem mainly surfaces when you have callbacks coming back into
scheme from C threads. Even if you have a global interpreter lock that
you pass around (something that I don't think guile provides for you --
we'll have to make this one ourselves), you have to protect against
invocation of continuations from other threads. This could be solved by
somehow correlating pthreads to dynamic roots, perhaps. This problem
makes my head hurt!

Of course, you still have the same old pedestrian issues of accessing
the same variable at the same time. Is it still a policy of guile's that
you shouldn't be able to crash the interpreter from scheme? Perhaps what
needs to be done in the long run is what Perl does with ithreads, see
perlthrtut(1).

** Fact 2: The X window system is also single-threaded ...

... and by extension, so are GDK and Gtk+. Either you can (1) enable
threading with g_threads_init () and put all of your idle-executed code
within gdk_threads_enter()/leave() pairs, or pass asyncronous messages
back to a designated "graphics thread".
