Re: Reasons to choose CLISP over other free implementations

Maciej Katafiasz <mathrick@xxxxxxxxx> wrote:
+---------------
| Rob Warnock:
| > 1. My first coding in CL[1] was for a database-backed web app,
|
| Did something eat your footnotes, or am I misunderstanding the notation?
+---------------

*Yikes!* Yes, "something" (my absentmindedness) ate my footnotes.
Let me try that portion again:

1. My first coding in CL[1] was for a database-backed web app,
and I initially used both CLISP & CMUCL, for quite a while,
but then settled on CMUCL because the compiled code for my
app was just *so* much faster, and also because the green
threads in CMUCL[2] were a very good match to my app. All
the initial development was done on FreeBSD 2.2.6, but was
later moved to FreeBSD 4.3, 4.6, 4.10, and now 6.2 with no
problems whatsoever.[3] Furthermore, the porting of the app
to Linux 2.4.21-40.EL (RH) was nearly as seamless, as was moving
to Linux 2.6.7 and then 2.6.20, and it's still running on all
those platforms. [Well, except FBSD 2.2.26 -- that machine died.]
So I clearly like CMUCL, on x86 platforms at least.
....


-Rob

[1] I had been doing serious coding in Scheme for ~10 years before
that, including some CGI apps that did HTML generation in Scheme,
so I hit the ground running with CL. [Yes, Kenny, I still owe
you all an RTL page...]

[2] CMUCL confusingly calls the package "MULTIPROCESSING", but it's
really multiprogramming, that is, "green" threads (co-routines)
within a single Unix/Linux process. But since CMUCL's threads
are very nicely integrated with its I/O so that by default *all*
I/O uses "select()", starting a new thread per HTTP request works
out extremely nicely. Some threads can block [waiting for a slow
input or output file descriptor to become usable] without blocking
others for which I/O is ready. The thread doesn't have to do
anything special to make this work, just use normal CL stream I/O.

[3] A warning for CMUCL users thinking of switching to FreeBSD 7.0:
Unlike FreeBSD 4.x, 5.x, and 6.x, which will happily run a CMUCL
that has been compiled on some earlier version of FreeBSD, via
the appropriate "compatN" libraries, the FreeBSD 7.0 beta changes
the signal handling [specifically, SIGBUS vs. SIGSEGV] in a way
that breaks CMUCL's GC. One of the CMUCL developers is currently
communicating with FreeBSD developers to try to resolve this issue.

-----
Rob Warnock <rpw3@xxxxxxxx>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

.

Relevant Pages

  • Re: dynamicness (dinamicity?) of lisp and its practical side
    ... A former system used FreeBSD with CMUCL. ... > production for that long in the face of all the critical kernel ... The current app only has about 30 users. ...
    (comp.lang.lisp)
  • Re: USB to Serial adapters: unplugging them
    ... FreeBSD 6.0 uses /dev/ttyU0, etc. ... The problem is that the device can still be opened by the app, ... it just thinks it's opened a serial port. ... It reverts to ttyUSB0. ...
    (comp.unix.programmer)
  • followup: IPv6 multicast sendto() operation not supported
    ... works on linux and on Solaris, but not on FreeBSD. ... To verify my app was OK, I installed a solaris box on the LAN beside the ...
    (freebsd-net)
  • Re: Which Lisp on FreeBSD
    ... I've been using CMUCL quite happily on FreeBSD & Linux [including ... CMUCL doesn't do multiprocessing, even though it has an extension ... It's *much* more reliable than the operating system underneath it ...
    (comp.lang.lisp)
  • Re: Serious compatibility breakage in -current.
    ... of CMUCL your first patch was tested against. ... executable was compiled on a FreeBSD 6.1 system. ... This is why the machdep sysctls for i386/amd64 are introduced. ...
    (freebsd-current)