I'm looking for a CL implementation to run on Linux that is both compiled
and has good multi-threading support (yes, I know that's a bit
non-standard). CMUCL seems to make reference to "Lisp Threads" in section
2.18 of the user manual, but all it says is "cmucl supports Lisp threads
for the x86 platform," with no information about how to actually use them.
Also, I have taken a quick look at CLISP. It doesn't have the compiler,
but I can't quite tell whether it supports threading or not. Can anybody
confirm/deny?
I know that some of the commercial platforms support both of these
features. I'm looking for something free (as in beer) to be able to learn
with. I'd like to write server-side programs which are typically
multi-threaded, and I want to be able to test the scalability of CL, so
I'd like a full compiler rather than bytecode interpreter.
-- Dave
Well, CMUCL threads are what is known as "userland threads" in that the
scheduler of the threads is part of the CMUCL runtime. I've written
several server-side web-applications with CMUCL, and can say that it
does work (though I do not know what kind of scalability you are talking
about here) and that the existing web-server software (which you should
investigate if that is what you need) makes good enough use of the
underlying mechanisms for multiplexing/multithreading for my purposes.
The CMUCL thread interface is based on the CLIM thread interface, and
you should take a look at the documentation of the exported symbols from
the MP package.
Having said that, there is a platform which offers an optimizing
compiler and "kernel threads" on the Linux/x86 platform, and that is
SBCL. http://sbcl.sf.net/
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish wrote:
> Well, CMUCL threads are what is known as "userland threads" in that the
> scheduler of the threads is part of the CMUCL runtime. I've written
> several server-side web-applications with CMUCL, and can say that it
> does work (though I do not know what kind of scalability you are talking
> about here) and that the existing web-server software (which you should
> investigate if that is what you need) makes good enough use of the
> underlying mechanisms for multiplexing/multithreading for my purposes.
> The CMUCL thread interface is based on the CLIM thread interface, and
> you should take a look at the documentation of the exported symbols from
> the MP package.
Great, thanks.
> Having said that, there is a platform which offers an optimizing
> compiler and "kernel threads" on the Linux/x86 platform, and that is
> SBCL. http://sbcl.sf.net/
I got the impression from reading the web page that SBCL was basically just
a fork of CMUCL that had been cleaned up a bit better for maintenance
reasons. Are the two now starting to diverge more (adding full kernel
threads is a pretty big feature)?
If SBCL has all that, it sounds like just the ticket.
Thanks,
- Dave
Dave Roberts <·····@re-move.droberts.com> writes:
> Matthew Danish wrote:
>
>> Having said that, there is a platform which offers an optimizing
>> compiler and "kernel threads" on the Linux/x86 platform, and that is
>> SBCL. http://sbcl.sf.net/
>
> I got the impression from reading the web page that SBCL was basically just
> a fork of CMUCL that had been cleaned up a bit better for maintenance
> reasons. Are the two now starting to diverge more (adding full kernel
> threads is a pretty big feature)?
It's quite hard to measure divergence in any objective manner. The
code bases are still sufficiently close that, as someone working on
the internals, moving from one to the other gives a creepy feeling of
/d�ja vu/, rather than the impression of being in a foreign land --
though there are some instances of culture shock. The practical
upshot of this is that bug fixes can (and generally do) flow
relatively freely between the two. In that sense, it's "basically
just a fork".
On the other hand, the two projects are maintained by different sets
of people, with different emphases on stability, maintainability,
user-friendliness and so on; in that sense, there will be
divergences. And, as you've observed, different needs or wants by the
maintainers or their users can lead to different features; in this
case kernel threads, but there are some others. Lest I fail to be
balanced, it should also be pointed out that CMUCL has features that
SBCL does not.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)