Green threads and Web-application

Writing Web-application and multiprocessing are closely related
subjects. Each new HTTP request gets processed in a separate thread in
AllegroServe (portable). Here comes the difficulties:

1. One foreign call hangs up all threads (no one of them works until
foreign call is done, actually the whole Lisp world is flat-out
hung for a while).

2. Even if a thread doesn't foreign call but computes something w/o
making any I/O all other threads also have to wait.

Visible outcome of the first mentioned point is that if one of the
users of the Web-application does something that causes issuing
foreign call he and all other users of the same application can't do
nothing until it is done.

Is there a way to overcome these difficulties in the CL implementation
with non :os-threads threading model (CMUCL for example)?

Yes, it is possible to use separate OS processes (instead of Lisp
threads) to handle HTTP requests in AllegroServe, in that case
however, there is no easy way for mutual communication among them no
more, no shared variables for example and the size of the each process
is some 30M, which is rather expensive.

One possible solution of the problem might be switching to another
Lisp with native threading like SBCL (for Linux, not for
FreeBSD). However it seems too much luxurious, especially if you
already have a bunch of applications written for another Lisp like
CMUCL.

The overcoming of #2 may be achieved by inserting MP:PROCESS-YIELD,
or (SLEEP 0), or whatever which 1) implies some knowledge of the code
being changed and 2) unfortunately it has nothing to do with the
difficulty #1

I'd appreciate if you shared some of your thoughts on this
subject. What is the proper and reasonable way to get robust web
application with green threads ?


--
Vladimir Zolotykh
.

Relevant Pages

  • Re: C-like Unions in Lisp (was Re: Why no compiler-macrolet?)
    ... - Our "foreign types" interface need not be used only for foreign types, ... test suites that ensure that the sizes and alignments of foreign structs ... in the target C/C++ compilers correspond to what the lisp foreign structs ... > all distilled down into modern SIMD instructions where possible. ...
    (comp.lang.lisp)
  • Re: Hutchentoot or Allegroserve?
    ... you can not demand stuff of a free software either. ... If somebody has enough money to spend, one way is to go with AllegroCL ... (Mind you, I'm talking about AllegroServe on AllegroCL, ... not about Portable AllegroServe on some other Lisp.) ...
    (comp.lang.lisp)
  • Re: Popularity of programming languages
    ... The LispM, of course, didn't have any "foreign" functions, since ... This facility was mostly used in the embedded Lisp ... What it generated was your RPC stub on the Lisp side. ...
    (comp.lang.lisp)
  • Re: Lisp-ifying FFIs
    ... A foreign interface is just that; ... > free now to go ahead and wrap OpenGL's gluCylinder with the lisp ... > vastly more important that the sacred ground of Lisp code not be ... Fortunately the gl package did not need to ...
    (comp.lang.lisp)
  • Hunchentoot vs. Portable Allegroserve
    ... Lisp to build a small application (a address & phone book) with a web ... I found and installed both Hunchentoot and Portable Allegroserve ...
    (comp.lang.lisp)