I've checked a bunch of implementations now. bt:*supports-threads-p* and tbnl::*supports-threads-p* are T for the implementations that work well with Hunchentoot. Typically both variables are NIL due to the underlying implementation lacking thread support:
Success
- Lispbox CCL on Ubuntu/Xen - Lispbox CCL on Mac OS X - MacPorts CCL on Mac OS X - Aptitude SBCL on Ubuntu/VMware - MacPorts SBCL on Mac OS X
Partial Failure
- Aptitude CLISP on Ubuntu/Xen (no threads; Hunchentoot server and command hang) - Fink CLISP on Mac OS X (no threads; Hunchentoot works with slight modification)
Failure
- Aptitude SBCL on Ubuntu/Xen (SBCL compilation fails) - MacPorts CLISP on Mac OS X (CFFI and threads missing) - Aptitude CCL on Ubuntu (no package named CCL) - ECL on Ubuntu/Xen (ECL compilation failure) - MacPorts ECL on Mac OS X (flexi-streams compilation failure) - ABCL on Ubuntu/Xen (Bordeaux Threads compilation failure) - MacPorts ABCL on Mac OS X (Quicklisp compilation failure) - GCL on Ubuntu/Xen (Quicklisp compilation failure)
Cheers,
Andrew Pennebaker www.yellosoft.us
On Tue, Mar 1, 2011 at 9:08 AM, Edi Weitz edi@weitz.de wrote:
On Tue, Mar 1, 2011 at 11:07 AM, Andrew Pennebaker andrew.pennebaker@gmail.com wrote:
I have installed ABCL, SBCL, CLISP, and ECL on Ubuntu and Mac OS X, using Aptitude and MacPorts respectively. In every case, Hunchentoot's start function hung, because the CL implementation failed to include thread support.
That should not happen. Can you check the values of bt:*supports-threads-p* and tbnl::*supports-threads-p*? Are they correct? If so, the default taskmaster should be one-thread-per-connection-manager which doesn't need threads.