httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: Shambhala
Date Sat, 01 Jul 1995 14:42:46 GMT
   From: Rob Hartill <hartill@ooo.lanl.gov>
   Date: Fri, 30 Jun 95 21:25:00 MDT

   > You must have missed my "Shambhala Rocks!" post shortly after Shambhala2.
   >   :-)

   I saw it, but all I read into it was that it was working well.

   So what's the plan. Are we going to feed Rob T bug reports/patches/requests
   or will we return to the patch'n'vote approach we once had.

Hmmm... past a certain point, the patch-n-vote business might be a
good thing to have regarding changes to the server core, and at least
some of the messier modules.  If the stuff on my TODO list is
offensive to anybody, it might even be appropriate to restart that
process now; however, that stuff will happen somewhat faster if I
don't have to package it up incrementally, so I'd rather go that way
for a little bit more unless someone really does have serious
objections.  (On the other hand, if you find a bug and fix it, please
don't let that discourage you from sending me the code!)

However, half the point of Shambhala is to make some of that process
obsolete, by allowing stuff which is not universally applicable
(e.g. database back-ends), controversial, or just half-baked, to be
shipped anyway as optional modules.  (Of course, the config script
which makes it easy for webmasters to pick and choose among the
options has yet to be written, but that's the intention).  Having a
middle way between tossing something in for everybody, and leaving it
out, might obviate some of the nastier votes we've had...

   I don't want to tread on Rob's toes, if
   he needs more time to work on the code alone, then that's okay, but
   I'm willing to put some time in to do some coding - if indeed there's
   any extra coding that needs doing... it'll take some time for everyone to
   find their way around a new code base whatever happens, so Rob has some
   legroom there.

Oh, there's no shortage of coding that needs doing...

   -=-=

   BTW, the minor problem I hinted at earlier was with a CGI script which
   spawned a child to do some real work, and the parent exitted.
   With Apache, the connection is immediately closed once the parent CGI exits,
   with shambhala, the connection stays open until the CGI child exits.

Hmmm... here's a hypothesis.  Shambhala is not as scrupulous about
closing spare file descriptors as it ought to be, and it does not
relocate the client file descriptors down to stdin and stdout
immediately.  So, the CGI script gets the direct connection back to
the client set, and the CGI child inherits it; as long as *any*
process has the socket open, the connection stays alive.  Looks like
I'll need a hook into alloc.c to allow child processes to clean up
their descriptor state before the exec...

   Oh, and one other thing, I had an AddType in one of my config files, and
   it had parameters after content-type, this gave a error message.

Could you send me the config line that breaks?  Thanks.

rst

Mime
View raw message