Hi Pete!
On Fri, 16 Jul 2004 12:31:07 -0400, pete-tbnl-dev@kazmier.com wrote:
Upon further thought, isn't this behavior to be expected? I.e. as requests come into Apache, and Apache dispatches them to one or more of its children (processes/threads), doesn't each child via the mod_lisp handler create its own connection to TBNL on port 3000? And since Keep-Socket is "1", this is the reason why I never see any of the sockets closing. Thus, I should expect to see a socket for every child Apache process/thread, right? Or does mod_lisp make sure the same socket is used for all cases? This does not appear to be the case as I do see TBNL accept more than one connection on port 3000. Obviously, I'm not very familiar with the Apache API or mod_lisp.
See the recent postings by Marc and myself. You've obviously found a bug in mod_lisp which is fixed now.
Back to my original problem, I'm still a little confused as to why I can't get a simple page that includes 3 style links (irrelevant I suspect other than it does cause multiple requests to occur in a very short amount of time perhaps on different sockets from the client) in it to load properly under any combination of mod_lisp, TBNL and lisp implementation. I've tried using SBCL, CMUCL, Apache 1.x (w/ modlisp-2.33), Apache 2.x (w/ modlisp for 2.x Apache). The symptom is the same, the web browser just sits there and hangs until the mod_lisp module times out reading from TBNL.
Debugging the mod_lisp module seems to indicate that mod_lisp just sits there waiting for a response from TBNL. This seems to only occur for one of the four initial requests that it sent to TBNL (one of the style links). My only guess is that perhaps TBNL is somehow writing its response to the wrong *apache-stream* as mod_lisp handler does open multiple connections to TBNL on port 3000. I'm new to lisp and I'm not quite sure how special variables work in a multithreaded app or one that uses the CMUCL event loop.
I look forward to your return Edi for some enlightenment! :-)
If it's not confidential then maybe you can just send me your code and I'll have a look at it. I currently don't have an idea what's the problem might be.
As for special variables: Although there's no standard for that there seems to be an agreement that every process/thread has its own set of bindings for special variables, i.e. if you do
(let ((*foo* ...)) ...)
within a thread and *FOO* is a special variable then within the body of the LET form the thread is manipulating its "private" version of *FOO* which is distinct from the value other threads have access to.
This is what happens in TBNL because of this line:
(defun apache-listen (*apache-stream* command-processor &rest args) ...)
When APACHE-LISTEN is called, the special variable *APACHE-STREAM* is bound. That would be equivalent to:
(defun apache-listen (apache-stream command-processor &rest args) (let ((*apache-stream* apache-stream)) ...))
If you haven't done so you might want to look at
http://cl-cookbook.sourceforge.net/process.html
which is about LispWorks but is nevertheless a pretty good general introduction to multi-processing in CL.
Cheers, Edi.
PS: TBNL (via KMRCL) doesn't use CMUCL's event loop but rather CMUCL's multi-processing facilities. It will therefore only work on x86 machines (unless you use other CL implementations, of course).