Maciej Katafiasz <firstname.lastname@example.org> wrote:
| Rob Warnock:
| > 1. My first coding in CL 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 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 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. 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.
 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...]
 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.
 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 <email@example.com>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607