future thread interface

future thread interface

[Christopher Cramer]

I have a few questions about where Guile is heading wrt to threads.

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.

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? Personally I would like to keep using coop threads until
pthreads on Linux/glibc gets much more efficient than it is now. I don't
use Guile on any multiprocessor systems, but I expect that eventually
the efficiency problems will be small enough to be outweighed by
the relative simplicity of pthreads.

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?

-- 
Christopher Cramer <crayc@pyro.net> <http://www.pyro.net/~crayc/>
"People said it couldn't be that our soldiers would do such things. Now
you read worse things in the mainstream media and people don't care. We
used to say that if only people know about it, it would stop. Now they
know about it, and it hasn't stopped." - Adam Keller


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: future thread interface

[Marius Vollmer]

Christopher Cramer <crayc@pyro.net> 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


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: future thread interface

[Christopher Cramer]

On Tue, Jul 01, 2003 at 12:27:07PM +0200, Marius Vollmer wrote:
> 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.

This is a surprising answer, since the code is clearly not written to
only use the pthread API. I suppose the goal has changed, and the code
doesn't reflect that yet.

Does that mean scm_internal_select will be eliminated?

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

So it's not coming back? The only other mention of this I could find was
a ChangeLog entry saying 'Support for "coop" threads has been removed
until I get time to add it again.'

-- 
Christopher Cramer <crayc@pyro.net> <http://www.pyro.net/~crayc/>
"People said it couldn't be that our soldiers would do such things. Now
you read worse things in the mainstream media and people don't care. We
used to say that if only people know about it, it would stop. Now they
know about it, and it hasn't stopped." - Adam Keller


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: future thread interface

[Mikael Djurfeldt]

Marius Vollmer <mvo@zagadka.de> writes:

> Christopher Cramer <crayc@pyro.net> 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.

I posted an analysis of the thread situation on this list before
Christmas.  I think you agreed with the conclusions.

Although nothing you say above really contradicts what we agreed upon
earlier, I wanted to post this message because one might get the
impression from your message that null-threads is intended to be
selected compile time only on platforms which don't have pthreads.

In contrast, among the conclusions were rather the need to enable the
application itself to select what thread package to use during Guile
startup.  I've written the latest thread code with this in mind.  The
API for this (threads-plugin.c) is intended to be mostly indentical
with the pthreads API, as you say, but will need to contain some extra
entries.  Note, though, that the code is not yet complete.  (I think
we agreed that you would complete the null-threads part, no? :)

Also, in my view, we should provide a rewritten version of COOP
threads as an option for this plugin interface.  (But that option
should be provided in a separate dynamically loadable library, while
pthreads and null threads are options provided in libguile itself.)

I'll commit my thread situation analysis text to the workbook.

Best regards,
Mikael D.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: future thread interface

[Marius Vollmer]

Mikael Djurfeldt <djurfeldt@nada.kth.se> writes:

> I posted an analysis of the thread situation on this list before
> Christmas.  I think you agreed with the conclusions.

Yes, I see now that I'm not being very consistent.  Unfortunately, I
don't have the, ahem, 'mental capacity' right now to do this topic
justice, so I'll better shut up for now.  Christopher, please listen
to Mikael about what is going to happen with the threads.

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


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel