Subject: [clisp-list] Re: Multithreading in CLISP

From: Daniel Lakeland <[email-masked]>
Date: Thu, 23 Aug 2001 09:16:21 -0700

What is the actual status of multithreading in CLISP? I've heard about
more and more people working on LISP based Web systems, and most wish
they had multithreading. CLISP multithreading would be extremely
valuable.

I know that you have limited resources and various priorities, but I
saw that it was being developed at one point. What has been done
recently?

What will it take to do, and how easy would it be to contribute to
adding multi-threading? I myself would like to have it, but don't know
how much I can contribute.

Also one more question. It doesn't seem possible to bind a socket to
listen on a given interface. How can I bind a socket that will listen
on anything other than 127.0.0.1?

Thanks for the work you've done!

Dan Lakeland

-- 
Daniel Lakeland
[email-masked]
http://www.endpointcomputing.com

---

From: Sam Steingold <[email-masked]>
Date: 23 Aug 2001 13:13:20 -0400

> * In message <[email-masked]>
> * On the subject of "[clisp-list] Re: Multithreading in CLISP"
> * Sent on Thu, 23 Aug 2001 09:16:21 -0700
> * Honorable Daniel Lakeland <[email-masked]> writes:
>
> adding multi-threading?

try building CLISP with -DMULTITHREAD and make it work on your platform.

> It doesn't seem possible to bind a socket to listen on a given
> interface. How can I bind a socket that will listen on anything other
> than 127.0.0.1?

I don't understand the question, but I think that the answer is
http://clisp.cons.org/impnotes.html#socket

-- 
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel>
Read what the Arab leaders say to their people on <http://www.memri.org/>
Daddy, what does "format disk c: complete" mean?

---

From: Sam Steingold <[email-masked]>
Date: 31 Aug 2001 14:59:33 -0400

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] Re: Multithreading in CLISP"
> * Sent on Fri, 31 Aug 2001 11:03:46 -0700
> * Honorable [email-masked] (Don Cohen) writes:
>
> Sam Steingold writes:
>  > 
> There are a number of topics, such as special binding and garbage
> collection.  What I thought (and still think) is the major problem is
> finding operations that should be regarded as atomic in lisp but
> require multiple heap accesses, and arranging somehow to protect
> these.

while, obviously, important, these issues are "step 1".
"step 0" is getting CLISP STACK and GC work with MT.
this is what I meant - just getting CLISP compile with -DMULTITHREAD is
a challenge (lisp.run compiles on Solaris and NT but crashes on startup).
after getting this, we can work on the rest.

-- 
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel>
Read what the Arab leaders say to their people on <http://www.memri.org/>
Never let your schooling interfere with your education.

---

From: [email-masked] (Don Cohen)
Date: Fri, 31 Aug 2001 11:03:46 -0700

> try building CLISP with -DMULTITHREAD and make it work on your platform.

This seems an appropriate place to reopen the discussion last seen on
this list (I believe) on July 22 about why MT is not so trivial.
After that message I reopened a corresponding discussion (from 1996!)
with Franz and got back some stuff that's worth sharing.
There are a number of topics, such as special binding and garbage
collection.  What I thought (and still think) is the major problem is
finding operations that should be regarded as atomic in lisp but
require multiple heap accesses, and arranging somehow to protect
these.  Here's a good example:

Robert F. Rorschach writes: (I hope he doesn't mind me quoting him)
         (aref some-adjustable-array index)
  should either get an error for the index being out of range or return an 
  element of the array.... it shouldn't be possible for the array to
  change size after the internal range test on index but before the
  element is fetched, causing a fetch from outside the actual array.

I assume it's not difficult to insert code to protect such an
operation (on a case by case basis), but I have no idea how to go
about identifying all of them.  And this is what would be needed
in order to make a reliable multithreaded Clisp.

Anyone out there have any ideas about this?  Even some idea of how
many such operations there are?