guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: future thread interface


From: Marius Vollmer
Subject: Re: future thread interface
Date: 01 Jul 2003 12:27:07 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Christopher Cramer <address@hidden> writes:

> 1. The goal is to be able to pick between different thread
> implementations. When is this choice actually supposed to be made: compile
> time, link time, during Guile startup, or when? Right now (looking at CVS)
> it's compile time, but it looks like the goal is during Guile startup;
> It just doesn't seem to be stated anywhere.

In my view, the goal is to avoid to have to chose.  That is, Guile
should be written against the POSIX pthread API only.  When people
have a need for a non-standard threading implementation, that
implementation should offer the pthread API and Guile can then use it
transparently.

We offer one such pthread-'ersatz' implementation with Guile:
null-threads.  This implementation is used on platforms that don't
have pthreads.  Null-threads do not offer real threading, but the API
is there and you can write your code in a thread-aware fashion even
when no threads can ever be created.

> 2. The prevailing view is apparently that at some point in time
> coop thread support will be completely dropped. When is this going
> to happen?

This depends on what you mean exactly with "coop" threads.  The coop
thread package based on QuickThreads has already been removed from
1.7.

But Guile is still using cooperative threading, to a degree.  It needs
all Guile-using threads to cooperate during a GC, for example.  This
kind of cooperation will likely be with us for a long time, and
probably forever.  The reason for this is that a concurrent GC leads
to a much more complicated programming model.

> Personally I would like to keep using coop threads until pthreads on
> Linux/glibc gets much more efficient than it is now.

The 'new' way is to code a cooperative package that offers a pthread
API.  Then we can make sure that Guile can use it.

> 3. A while ago I was working on a patch to eliminate all the blocking
> caused by accept/connect/etc. If I finish it now, can it possibly included
> in 1.6.5 (or in 1.6.x at all), or should I target the patch for 1.7?

I don't see such a large patch going into 1.6.  Please concentrate on 1.7.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405




reply via email to

[Prev in Thread] Current Thread [Next in Thread]