Re: Thread support plan with initial patch

[NIIBE Yutaka]

Mikael Djurfeldt wrote:
 > Example: An application writer wants to use GTK together with COOP
 > threads.  The way to do this is to plug in COOP threads into glib's
 > thread interface.  (An implementation of this exists as the CVS module
 > guile-gtkthreads.)  However, this requires linking with libgthread,
 > which, in turn, is linked with libpthreads...
[...]
 > I'd like to know what the problem is

Yes, I will try to find the problem...

Anyway, again here's what I think:

In C Library (or X11 library) which supports multi-threaded
application, there're the places to call of POSIX threads, so that
critical sections are protected.  Those will be enabled when
libpthreads is linked explicitly, or else, it calls null function.  It
is implemented using weak symbols.  This is the trick of
multi-threaded library.

Consider the following case:
An application writer do *not* want to use POSIX threads feature, but
just only COOP threads feature.  He does *not* link the application
with libpthreads.  However, if libguileqthreads are linked with
libpthreads (and this is the case, now), it loads POSIX threads
automatically.  Because POSIX thread implementation is not designed
for COOP, it is difficult to support this case (in my opinion).

Well....  OK, for now, how about having two?

 (1) libguileqthread-pthread
     Compiled with GUILE_PTHREAD_COMPAT and linked with libpthread
 (2) libguileqthread
     Compiled with no GUILE_PTHREAD_COMPAT and linked with
     no libpthread

Then, Guile loads the one of them on start-up time, examining the
application (if the application is linked with libpthread, it load
libguileqthread-pthread, or else libguileqthread).

This is cleaner approach, and we can test loading different threads
implementations.  Then, add (3) POSIX threads support.  Perhaps, 
one could deprecate (1) at that time.
--