Subject: [clisp-list] Threads?

From: [email-masked] (Don Cohen)
Date: Thu Jan 30 08:14:03 2003

> What would be the difficulty to have threads in CLISP?

I refer you to the extensive discussion of this topic in the list archive.

Summary:
It's much worse than you imagine.  In addition to the low level
problems that you mention, many pieces of code assume they are
running alone and would have to be modified to do locking.
My guess is that, in addition to a large amount of work on the part of
some very knowledgeable developers (who are in short supply), users
of multiple threads would suffer a prolonged period of instability
during which bugs were found and fixed.  And these bugs are
particularly difficult to reproduce.

 > I guess  that the  garbage collector would  have to block  the threads
 > while doing its  work, but is there any  other difficulties that would
 > occur with threads?

Clearly some locking is needed.  There are gc algorithms in which gc
runs as "just another thread" without blocking any others (other than
locking particular objects while it's using them).

 > What if we use them thru FFIs in LINUX package?

There's no problem using threads in foreign calls as long as they
don't affect the lisp thread.

---

From: Sam Steingold <[email-masked]>
Date: Thu Jan 30 08:49:05 2003

> * In message <[email-masked]>
> * On the subject of "[clisp-list] Threads?"
> * Sent on Thu, 30 Jan 2003 08:10:55 -0800
> * Honorable [email-masked] (Don Cohen) writes:
>
> problems that you mention, many pieces of code assume they are running
> alone and would have to be modified to do locking.  My guess is that,
> in addition to a large amount of work on the part of some very

I think the amount of work is not that bad.
we do need a knowledgeable developer, but most of the design is already done.

> knowledgeable developers (who are in short supply), users of multiple
> threads would suffer a prolonged period of instability during which
> bugs were found and fixed.  And these bugs are particularly difficult
> to reproduce.

the user will have to ensure that his objects are not modified by
different threads at the same time.  CLISP will not do that for you.

> locking particular objects while it's using them).

they make heap access "interesting"...

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
To a Lisp hacker, XML is S-expressions with extra cruft.