Hello,
Is there an easy way to find out of Hunchentoot is using threads to handle requests? I'd like to issue a warning on single threaded systems, and I'm wondering if there is a unified way to get this information.
Thanks, Slava Akhmechet
On Fri, 15 Feb 2008 15:37:53 -0500, "Vyacheslav Akhmechet" coffeemug@gmail.com wrote:
Is there an easy way to find out of Hunchentoot is using threads to handle requests? I'd like to issue a warning on single threaded systems, and I'm wondering if there is a unified way to get this information.
As a general rule, Hunchentoot should only be used in a multi-threaded Lisp... :)
Some users convinced me to support Lisps without MP, but this is only for testing purposes and is frowned upon. The two possibilities I'm aware of are:
- SBCL on some platforms; in this case Hunchentoot will issue a warning anyway. (See top of port-sbcl.lisp.)
- CLISP; this Lisp doesn't have MP at all.
Edi.
On 2/15/08, Edi Weitz edi@agharta.de wrote:
SBCL on some platforms; in this case Hunchentoot will issue a warning anyway. (See top of port-sbcl.lisp.)
CLISP; this Lisp doesn't have MP at all.
There's also OpenMCL running on intel chips. It might have support for threads now (I am not sure), but at some point quite recently it didn't.
I'll just look for SB-THREADS and whatever alternative OpenMCL offers.
On Sat, 16 Feb 2008 02:06:04 -0500, "Vyacheslav Akhmechet" coffeemug@gmail.com wrote:
There's also OpenMCL running on intel chips. It might have support for threads now (I am not sure), but at some point quite recently it didn't.
There's also CMUCL on some architectures. But your question was about Hunchentoot. I'm pretty sure Hunchentoot won't even compile on OpenMCL/CMUCL without threads.
CMUCL does not have threads. It does have multiprocessing based on SERVE-EVENT which is implemented in the Lisp runtime, as opposed to Lisp with threads that uses platform (often POSIX, but sometimes also Win32) threads to implement Lisp multiprocessing. The distinction is important because in a threaded Lisp, the scheduler is typically implemented in C as part of the system threads library, whereas in CMUCL, the scheduler is implemented in Lisp. Both approaches have advantages and disadvantages. The major advantage of Lisp processes implemented as native threads is that scheduling can occur while a Lisp process is executing foreign code, whereas with a Lisp scheduler, entering a foreign function will prevent scheduling. Also, Lisp multiprocessing with native threads (theoretically) allows for symmetric multiprocessing within one Lisp process, although many implementations do not support that. Contrasted to that, Lisp based multiprocessing on CMUCL is cooperative (processes are not interrupted, but they may yield to allow scheduling of other processes) which simplifies some applications. Also, as the scheduler runs in Lisp, it is possible to call Lisp functions from the scheduler, which makes it easy to implement queues and other multiprocessing synchronization mechanisms that, with native threading, require the use of system-defined primitives.
For many applications, cooperative multiprocessing is easier to work with as there are fewer hazards. Processing is synchronous, and processes do not need to worry about being rescheduled unless they voluntary give up control (either by sleeping, waiting for I/O or explicit yield). I had great success with running web and general event processing servers on CMUCL with portableaserve as HTTP server. I would like to see Hunchentoot support CMUCL in the future and will put some effort into testing it with the upcoming cmucl-19e release.
-Hans
On Feb 16, 2008 10:55 AM, Edi Weitz edi@agharta.de wrote:
On Sat, 16 Feb 2008 02:06:04 -0500, "Vyacheslav Akhmechet" coffeemug@gmail.com wrote:
There's also OpenMCL running on intel chips. It might have support for threads now (I am not sure), but at some point quite recently it didn't.
There's also CMUCL on some architectures. But your question was about Hunchentoot. I'm pretty sure Hunchentoot won't even compile on OpenMCL/CMUCL without threads.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Sat, 16 Feb 2008 11:30:54 +0100, "Hans Hübner" hans@huebner.org wrote:
CMUCL does not have threads. It does have multiprocessing based on SERVE-EVENT which is implemented in the Lisp runtime, as opposed to Lisp with threads that uses platform (often POSIX, but sometimes also Win32) threads to implement Lisp multiprocessing.
Yes, the same (in a similar way) is true for LispWorks pre-5.
For many applications, cooperative multiprocessing is easier to work with as there are fewer hazards.
Not to mention that "native" MP on Linux often has a recent kernel as a requirement whereas for example CMUCL or LW 4.x will also run on old kernels.
I would like to see Hunchentoot support CMUCL in the future
What about now? There's port-cmu.lisp and friends...
Edi.
On Feb 16, 2008 12:03 PM, Edi Weitz edi@agharta.de wrote:
What about now? There's port-cmu.lisp and friends...
I must admit that I am waiting for cmucl-19e before looking at it again as I have some hope that it will support Unicode. Once it is out, I will be reporting possible problems.
-Hans
"Hans Hübner" hans@huebner.org writes:
The major advantage of Lisp processes implemented as native threads is that scheduling can occur while a Lisp process is executing foreign code, whereas with a Lisp scheduler, entering a foreign function will prevent scheduling.
You may want to read the "tackling the awkward squad" paper by Simon Peyton Jones. It's done in Haskell, but it would be awesome to see in Lisp. Basically, there is a native thread per CPU for computation, coroutines-based threads (like Erlang or CMUCL) on top of those for abstraction, asynchronious IO to avoid blocking, and thread pool for native calls (again, to avoid blocking). The way of the future, IMO.
Edi Weitz edi@agharta.de writes:
I'm pretty sure Hunchentoot won't even compile on OpenMCL/CMUCL without threads.
I don't know about CMUCL, but I did get reports of runtime issues on non-threaded OpenMCL. There were no compilation issues. (Perhaps it was an older version of Hunchentoot).
Anyway, there aren't that many cases to look for. I was just wondering if function exposes a THREADED-P function before I rolled my own.
I think I missed to point out that "threaded" is not the right word to use. What you want to know seems to be whether the current Lisp supports multiprocessing, or am I wrong?
-Hans
On Feb 16, 2008 8:50 PM, Slava Akhmechet coffeemug@gmail.com wrote:
Edi Weitz edi@agharta.de writes:
I'm pretty sure Hunchentoot won't even compile on OpenMCL/CMUCL without threads.
I don't know about CMUCL, but I did get reports of runtime issues on non-threaded OpenMCL. There were no compilation issues. (Perhaps it was an older version of Hunchentoot).
Anyway, there aren't that many cases to look for. I was just wondering if function exposes a THREADED-P function before I rolled my own.
-- Regards, Slava Akhmechet.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Sat, 16 Feb 2008 14:50:47 -0500, Slava Akhmechet coffeemug@gmail.com wrote:
I don't know about CMUCL, but I did get reports of runtime issues on non-threaded OpenMCL. There were no compilation issues. (Perhaps it was an older version of Hunchentoot).
I haven't used Hunchentoot with OpenMCL for quite some time, but it looks to me as if Hunchentoot will call CCL:PROCESS-RUN-FUNCTION if a request comes in. What does that function do in OpenMCL if there's no MP? Does it even exist?
-
Edi Weitz -
Hans Hübner -
Slava Akhmechet -
Vyacheslav Akhmechet