[Lispweb] lisp implementations and threading

[Pierre R. Mai]

Jeff <jlb at houseofdistraction.com> writes:

> Daniel Barlow wrote:
> 
> >Except for SMP I'm not sure what native
> >threads buys on a Lisp, given that (a) userland threads can be faster
> >anyway, and (b) all "normal" IO gets channeled through the library in
> >such a way that it can be made non-blocking.
> >
> SMP is the probably the most important benefit of kernel threads but
> there is another area for which preemptive scheduling is almost
> essential:  interactive applications.

Note that the issue of kernel vs. user-threads and preemptive
vs. non-preemptive scheduling is completely orthogonal (well for most
current platform kernel threads imply preemptive-threading, but that's
just "coincidence").

Currently CMU CL supports user-threads with cooperative scheduling,
because although there is support for interrupt-driven scheduling,
large parts of the run-time support hasn't been written with that kind
of preemption in mind, and hence using preemptive scheduling is always
a gamble.

> :-)  That said, I am curious to know how difficult it would actually
> be to add preemptive threads to SBCL.  Is GC is the only issue or are
> there other parts of the system which would need extensive
> modification?

As far as I understand, Douglas T. Crosher, the CMU CL core developer
who developed the MP support for it, and who was/is now working on
kernel-threading support for (a commercial variant of) CMU CL, had
gotten far with the core low-level threading support, but came to the
conclusion that much hard work was necessary to rewrite all the other
portions of CMU CL (runtime, compiler and CLOS/PCL) to safely work in
a preemptive environment, and since he needed some form of funding for
such work to continue, turned it into a commercial venture (targetting
the server market, IIRC).  I'd think that anyone interested in
preemptive (kernel-assisted) threading for CMU CL would do well to
contact Douglas personally (AFAIK dtc at scieneer.com)...

Regs, Pierre.

-- 
Pierre R. Mai <pmai at pmsf.de>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein