Subject: Re: Multiple Threads: Costs, Benefits

From: Simon Brooke <[email-masked]>
Date: Sun, 17 Sep 1995 22:29:41 +0100

If you're going to operate multiple processes with access to a shared
LISP environment then the place to build those processes is within the
environment and not at operating system level. Let's face it, a LISP
system running on top of a non-LISP operating system is a bit of a
bastard anyway -- it's best to think of the operating system (yes,
even UNIX) simply as a boot loader.

Then all you need is a LISP process scheduler a la spaghetti stack to
handle task switching. There's no cost to interprocess communication
because all processes operate in the same LISP image. This is fairly
simple to do.------- simon@rheged. (Simon Brooke)

	'graveyards are full of indispensable people'

---

From: Marcus Daniels <[email-masked]>
Date: Sun, 17 Sep 1995 22:49:46 GMT

>>>>> "Simon" == Simon Brooke <[email-masked]> writes:

Simon> If you're going to operate multiple processes with access to a
Simon> shared LISP environment then the place to build those processes
Simon> is within the environment and not at operating system
Simon> level. Let's face it, a LISP system running on top of a
Simon> non-LISP operating system is a bit of a bastard anyway -- it's
Simon> best to think of the operating system (yes, even UNIX) simply
Simon> as a boot loader.

I think it is okay to organize a LISP implementation as either a
system or a component.  I also think it was a mistake of the early
Lisp vendors not deliver their products as libraries.  Today, this
mistake has been corrected by some of the more progressive vendors
like ILOG, and in some freely available implementations like CLiCC,
ECL, and WCL.

It is true that Lisp threads offer a unique capability.
If someone finds that they desire this capability, the sources are
ready and waiting, thanks to network CVS.  Email me for details.
Better yet, email me when you have code to commit.  ;-)