[tbnl-devel] Odd behavior (socket leak)

[Edi Weitz]

Hi Pete!

On Fri, 16 Jul 2004 12:31:07 -0400, pete-tbnl-dev at 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).