Re: Thread support plan with initial patch

[NIIBE Yutaka]

Mikael Djurfeldt wrote:
 > The reason is this: Many libraries that Guile might want to use are
 > linked with libpthread.  (There can also be a situation where an
 > application wants to use pthreads but run COOP threads within one of
 > its threads, but that is perhaps more exotic once we have a
 > guilepthreads implementation.)

I agree that it made sence.  GUILE_PTHREAD_COMPAT was needed, because
the threads support was in monolithic Guile.  Here, I mean, the
factoring-out of threads, and future.

Well, I don't think there is enough reason to keep
GUILE_PTHREAD_COMPAT *after* the factoring-out of threads
implementation.  If the application is linked with libpthreads, Guile
should load the suport library of Posix threads, not COOP threads.

Therefore, I think that there's no reason having GUILE_PTHREAD_COMPAT
in COOP support library.  Pthreads and COOP are totally different
beasts.  Combining them is a kind of ugly hack (sorry), it depends
much on both implementations.  It may work, but it's very difficult to
maintain it, in practice.

I think that it's OK not supporting COOP within pthreads.  If someone
really wants user-threads in a kernel-thread, we should provide the
feature with another threads library (which supports user-threads in a
kernel-thread).  It's not the business of Guile, IMNSHO.
--