[199] in Pthreads mailing list archive
Re: pthreads
daemon@ATHENA.MIT.EDU (Joe Keane)
Fri Nov 3 06:11:46 1995
Date: Fri, 3 Nov 1995 02:24:05 -0800
From: Joe Keane <jgk@netcom.com>
To: "William S. Gribble" <grib@cs.utexas.edu>
Cc: lord@cygnus.com, gel@cygnus.com, pthreads@MIT.EDU
In-Reply-To: <199511020239.UAA11994@cascade.cs.utexas.edu>
"William S. Gribble" <grib@cs.utexas.edu> writes:
>how much do you want to put Guile in bed with threads
They should at least not dislike each other. There are various models that
people may use, and ideally Guile should be able to work with all of them.
Some applications may be entirely single-threaded; others may be generally
single-threaded but with some signal handling. Then there are a variety of
threads packages, from simple user-level hacks assuming cooperative threads
(like the Macintosh), to full-blown OS support including multi-processing.
Another model is multiple processes that operate on common data structures
stored in shared memory. It may be non-trivial for Guile to work with this,
but there shouldn't be anything that makes it absolutely impossible.
For example, the current garbage collector has advantages of convenience and
efficiency in implementing primitives. But i think that it won't work so well
in a really parallel environment; in that case we probably want primitives to
allocate real GC-protection frames instead of relying on stack scavenging.
I think that Tom definitely has the right approach: specify a bunch of macros
and protocols for using them, and allow people to define these as appropriate.
In simple cases, many of these will expand to nothing, but in more complicated
cases they may involve latches, OS semaphores, memory barriers, and so on.
Of course someone writing a primitive may choose to ignore these protocols,
with the result that their primitive really only works with single-threading.
That's probably fine in many cases, especially if they're just prototyping,
but i think that the Guile core should use the most conservative protocols.
