Re: Thread support plan with initial patch

[Mikael Djurfeldt]

Marius Vollmer <address@hidden> writes:

> NIIBE Yutaka <address@hidden> writes:
> 
> > To change the threads support dynamically [...]
> 
> Hmm, do we want that?  I think it is sufficient to be able select the
> thread implementation at Guile startup time.

Yes.  It is sufficient that the application developer chooses which
thread library he wants to use, in the same way as with libglib.

To support dynamic selection would need a tremendous machinery, and
add overhead.

Most of the details of how this will work are already sorted out.
It is isn't very complicated.

There is a C stucture, scm_thread, which holds a few values and
pointers to all C-level thread functions.  The default values of these
contain pointers to a null thread implementation, where most calls
generate errors, while a few actually still works.  E.g., the null
implementation of mutecis will work, replacing the current "arbiters".

libguile contains Scheme level primitives which sits on one side of
the scm_thread interface.  libguilepthreads (and libguilecoop)
contains the implementation on the other side of the interface, and
which, in turn, linkes to the real thread library.  The scm_thread
interface is designed in a way that, for example, libguilepthreads can
plug in the raw libpthread functions directly into the scm_thread
interface.  Also, Guile C code can use the scm_thread slots directly,
as in scm_thread.mutex_lock, so that the only overhead in this call is
one pointer indirection.

A lot of the details are already implemented by Dirk in his thread
branch.  Some details should exist in a few emails between Dirk and
me.  (Dirk, do you have these documents, or should I try to find them
during the weekend?)

/mdj