Re: threads in 1.7.1

[Julian Graham]

Wow, Marius, thanks for all the replies.  Regarding thread
cancellation, I've taken a stab at implementing it and may send you a
patch once I've done some more testing -- I suppose that's a topic for
the developers' list, though.

>From looking at the new 'pluggable' thread interface, though, it
occurred to me that it would be easy to add support to alternate
threading libraries, such as GNU Pth, which does coop-threading; as
far as I can tell, though, they'd only be useful for applications that
were also using that threading library (the glibc pthreads
implementation does not play well with Pth).  This might have benefits
for Windows support, where there wouldn't be a compatible threading
library available "out of the box" (i.e., the user would have to
choose to install a threading library like pthreads-win32 or Pth), or
for people who have some kind of religious aversion to pthreads.


On Mon, 18 Oct 2004 17:54:41 +0200, Marius Vollmer
<address@hidden> wrote:
> Neil Jerram <address@hidden> writes:
> 
> >    (I'm not sure of the rationale for dropping coop threads;
> > personally I'm a fan of them.)
> 
> I, too, am a fan of coop threads.  In Guile, however, there was little
> difference between coop threads and preemptive threads for a Scheme
> program: even the coop threads could get preempted at any time in a
> Scheme program.  The advantage of coop threads was on the C level,
> where they made thread-safeness easier.  I'm quite sure now that we
> can handle the C level for real concurrent threads, so the advantages
> of coop threads mostly disappear.
> 
> The switch to POSIX threads was mostly motivated by compatability, and
> to avoid maintaining a thread implementation of our own.  Guile should
> be useable together with other code that used POSIX threads.  If you
> want to have coop threads, you would need to use a POSIX thread
> implementation that is coop.
>