Re: future thread interface

[Mikael Djurfeldt <djurfeldt@nada.kth.se>]

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