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: fd leaks
Date Mon, 29 May 1995 19:35:47 GMT
   From: Rob Hartill <hartill@ooo.lanl.gov>
   Date: Mon, 29 May 95 17:21:27 MDT

   Maybe if we just shifted all the global variables into a
   record which followed the current connection. If all the routines
   refer to the record instead of global variables, we'd be one step
   closer to having a reentrant server. Linked lists could be used
   to store dynamic info such as open file descriptors, environment
   varibles etc.

That's actually more or less the approach I took to at least *that*
set of problems with my "noodling server", now rechristened Shambhala,
since it feels about that far from reality (though I'm now getting
perilously close to having code that links, if not actually running).

FYI, a similar approach to resource management is used in several
compilers (at least gcc and lcc), which have separate resource pools
for the current statement and current function, and ditch the queues
when they're done with, well, whatever.  (In fact, the Lisp Machine's
compiler basically did the same thing ages ago, when their real
garbage collector wasn't exactly working yet).

   How difficult would this be ? anyone have a feel for it ?

It's taking me a while, but then again, I'm trying to offload
everything I can into modules which interact with the base code
through an API.  Depending on your tastes, that could be considered
more trouble than it's worth...

   All the routines would need a parameter to point to the current
   record. That looks like the biggest starting problem, but if all
   routines were changed to have the 1st param be the pointer, it could
   be implemented reasonably quickly. I'm willing to do that if it's
   worth the effort.

   thoughts ?

You need to distinguish between those globals which can vary per
request (and need to be cleaned out) and those that don't; they go
into different records (per-transaction and server config).  Keep-
alives would add a third level at least, since the proposals I've seen
all feature some state which stays live across transactions.  

(Incidentally, some globals are easier to scrap than to record-ize
even if you're trying to avoid a really thorough rework; for instance,
the auth_foofile variables are always copied right out of the sec
structure which is *pointed to by a parameter* of check_auth!.
There's a slippery slope here, though, as I ought to know, being most
of the way down it).

rst



Mime
View raw message