You might try to get manual entries here:
http://www.tf-ten.switch.ch/cgi-bin/clman
Use these starting points:
#!
#!PS-Adobe-3.0
Please let me know if you know of a public manual source.
In a word: This is quite the opposite of my wishes, I want a model with tight binding to a narrowed operating system thread model.
ecl/src/doc.
Alternativly, get a preformatted dvi file from ftp://ftp.di.unipi.it/pub/lang/lisp/ecl-man.dvi.gz.
The ILU project somewhat suffers from decreasing interest in Common Lisp. If you are interested in it, give them some feedback.
Thanks to Jean-Christophe Pazzaglia for the hint.
[TODO: Rscheme has threads? What it SIOD who had?]
Anything below this point is still in the works and just a snapshot of a brain in fluid state. Remember, you're reading work in progress.
(with-lock-held ...). [I think that is not
enough. At least seperate "lock" and "unlock" functions are needed in
addition to the progn-like construct.]
The CLIM specification uses strings to name lock resources. Why? At the
first look, Symbols will be faster and more straightforward to
use. What did I overlook?
setf -able.
process-unlock, which will fail when the lock
is held by another thread. But what if the current process is the
holder of the lock and just wants to see whether it already locked it,
just to be sure? [I wonder how that is related to the recursive
locks in the CLIM model.]
make-lock function has an optional argument
to lock the lock when it is created, so you can avoid an additional
call to the locking function.
process-reset function as
Symbolics Genera. I think this can be a very useful feature to avoid
creating threads everytime one is needed. Reusing threads (like in
"thread pools") is important for accepatable performance in
environments that use a single thread only for a small task (like
TCP-based servers, especially for protocols like HTTP).
The documentation is very good, with a lot of useful examples.
setf -able, in Allegro you have functions to add and
remove arrest reasons. [Is the Lispworks solution more elegant?]
process-wait function that
evaluates a function. [How time-intensitive is it to simulate
simple MUTEXes with the latter?]
nil takes time.]
nil if
lock is not locked). [TODO: Lispworks doesn't have this?]
process-reset function.
symeval-in-stack-group ca be used to
look up a special variable in a certain stack group. [Will have
to make up my mind about it...]
The maunal has a nice entry about multitasking and stream issues in
multithreading (page 21-24 in the postscript file linked to above).
First, let me describe my current needs for a thread interface to Common Lisp.
This should make it easier to use one of these OS thread systems as an underlying construct. To support multiple CPUs with multiple threads it is a requirement to use either the native userlevel thread mechanism or to build an interface to the lightweight processes (LWP).
Terminology I use here: "Threads" are what is running in the userlevel process, a "leightweight process" is what the operating system kernel shedules, basically, a full process that shares its memory pages with others (rfork(2) call in plan9 and FreeBSD, clone(2) in Linux).
As far as I can see, no Thread library on an operating system has the neccessary functionality to base a garbage-collected system with its own stack management on. My own plans are to use the rfork() and clone() calls on FreeBSD and Linux and let the Lisp system do the whole synchronisation management, probably taking code from existing userlevel libraries.
I know, if the whole issue of interfacing with OS threads would be that easy, some of you already did so. But let me take the freedom to work in that direction until I hit the wall :-)
My needs for threads include multiplexing network servers and using multiple CPUs for CPU-intensitive tasks. I think these task depends more on efficient thread switching than GUI work (where, pardon my ignorance, the typical situation is a very small number of threads and a clear idea of what the "main" thread is). Therefore, I think some of the existing meachnisms in Lisp systems are not right for my tasks.
It may be a good idea to include an optinal proposal for a
high-level interface to an operating system's timer
interface. Something like (set-periodic-function [funcname]
[args] [:flags]), where the flags control what happens on
simultanous runs of that function.
Is it useful to specify a "Stack Groups" interface when you define a thread interface anyway? "Stack Groups" accessable by the user allow other useful applications.
In which Lisps can you save a world with multithreading active? If so, what happens to running stacks? Solving this would in first line require to have a clean solution for the "controlling listener" for each thread. The Listener concept I'm thinking about maps one or more threads to a specific listener and each listener to one controlling stream/window. If its possible to change the controlling device for a listener "on the fly", the whole saving problem will become much easier. Just reassiciate every listener and its threads to a device that is availiable after reloading (i.e. change those listeners that used files that are not longer open or windows that no longer exist). A hook mechanism should be specified to notify a thread that it's output device has been changed and the thread decides whether it is still useful to continue workign with the new device.
I think I really want a stop/resume functionality. It will be neccessary anyway for most GCs and is probably useful to make threads survive saving and reloading the world.
Is it true that on most Lisp implementation the smallest availiable sheduling quantum is 1 second. If so, why don't the manuals list it?
©2007 Martin Cracauer $Id: lisp-threads.html4m,v 1.8 1998/05/27 17:01:08 cracauer Exp $