httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: [PATCH] pool confusion (take 1)
Date Mon, 10 Nov 1997 19:47:44 GMT


On Mon, 10 Nov 1997, Alexei Kosut wrote:

> It has to be performed in *both* the child and the parent, because
> they *both* have a copy of pconf. Seperate copies. Calling a cleanup
> on one doesn't clean up the other (unless you're suggesting that pconf
> should be made shared memory, which I highly doubt you are).

No, consider fopen().  Notice how when you clean that up it's cleaned up
differently due to a fork() (which is about to exec()) than it is due to
the pool being cleaned.  I'm saying the same thing exists between the
parent and child.  There are cleanups that need to be performed exactly
once, and that exactly once has to be when the parent restarts. 

For example, piped logs.  They're registered in pconf, and MUST NOT be
cleaned by the child because the resource they register is another pid; 
and the cleanup they do is to kill off that pid.  Note that the children
don't get a copy of this other task, they share the same task with the
parent.

Another example is flock().  Prior to this patch it couldn't use the
register_cleanup mechanism to clean up its resource because the cleanup
must be run exactly once; by the parent.

> > > Admittedly, the subsequent exit() does get rid of the said memory, but
> > > this is the only example I can think of off the top of my head.
> > > 
> > > I am convinced, however, that it is neccessary in some cases.
> > 
> > This is what pchild is for.  If something needs to be cleaned up when the
> > child exits, then it's probably only created when the child starts.  One
> 
> "probably." I'm saying that this isn't always true. I buy your
> rationale that many things only should be cleaned up by the parent,
> but not everything. If you're going to do this, then I suggest
> creating pchild at the same time as pconf. That way, you always have
> an appropriate pool to use.

There is nothing stopping a module from registering something in pconf
during init(), and re-registering the same/similar cleanup in pchild
during child_init().  So the functionality is already there.  I don't want
pconf and pchild to be available outside http_main; they're passed to
init_modules() and child_init_modules().  That's the thread-safe way to do
things... globals suck.  I'm not sure why pconf is global currently...

Dean



Mime
View raw message