Re: Thread support plan with initial patch

[NIIBE Yutaka]

Rob Browning wrote:
 > Let me start by saying that I probably I don't understand the
 > situation well enough to make sure I'm making any sense here, but if
 > it turns out that fixing the problem in guile is really hard given the
 > current pthreads "self" implementation, I wonder if we might be able
 > to come up with an alternate implementation and get it accepted
 > upstream...

Thanks.  You mean GNU C library, don't you?  Actually, I work for GNU
C library too (just a little).  My main work these days is a port of
SuperH.  (SuperH is used as main processor of Dreamcast.)  We're about
to implement THREAD_SELF for SuperH.  That is the reason I found the
problem.

I don't think it is good interaction to demand the change of
LinuxThreads.

I think that it would be good if we could drop our own support of
thread library in Guile.  And not depends much on *the implementation*
of those.  Instead, we should design/define good *interface* to avoid
confusion.

I mean, Guile only provides (hopefully stable) supports for thread
libraries (cooperative thread library, kernel thread library, and
kernel+cooperative thread library, possibly different
implementations).  Guile users can use one of thier favorite.

Maintaining thread library with Guile sounds bad idea for me.
Perhaps, eight years ago, it made sence because there's no standard
thread library support in most system.  I think that we have two or
three implementations which have same interfaces now.  If Guile can
support them, there's no reason for Guile to have its own thread
implementation.
--