httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <>
Subject Re: child_exit
Date Tue, 17 Mar 1998 00:15:16 GMT
Dean Gaudet wrote:

> On Tue, 17 Mar 1998, Doug MacEachern wrote:
> > so, we don't need child_exit because we can just use register_cleanup
> > with the pool who has a lifetime of the child (is there a name for
> > that?).
> pchild, but you're not touching that.  It's local to http_main.  modules
> get passed it as the parameter to child_init(), save that if you need it.
> > Why not keep the child_exit hook for modules (in the module
> > structure), but add a child_init to core_module which registers a
> > cleanup that will invoke child_exit_modules()?  This way, modules who
> > are using child_exit don't need to change, and plugin developers who
> > want child_exit-ness can avoid the awkwardness of using
> > register_cleanup().
> But child_exit is a new function for 1.3, and MODULE_MAGIC_NUMBER lets
> folks do things whatever way they need to... and the php, jserv, and perl
> folks are all here on this list reading this and cursing me :)

I still consider 1.3b1..1.3b5 "minor releases", I'd rather see backwards
compatibility than more MODULE_MAGIC_NUMBER hacks.  Let's say 1.3b6 is
released with child_exit removed, now I have to release a new mod_perl that
adapts to that, and users who are trying to build with 1.3b6 have to stumble
over this, download the new version of mod_perl, etc.  I know, I know, it's a
"beta phase", but the smoother we make it, the better, IMHO.

> If we're going to keep the child_exit method, why should we complicate how
> we invoke it?

I think this would be simplifying it, in the eyes of module developers, at

> What is awkward about register_cleanup()?

Don't get me wrong, I'm a BIG fan of register_cleanup().  But, it's not as
intuitive as a module hook named "child_exit" in this case.

> There are cases where modules absolutely have to use this function instead
> of child_exit because cleanups give you a chance to cleanup across
> fork()... yet another reason that child_exit() is not a useful addition to
> the API.  I should have been far more adamant with my complaints way back
> when this method went into the API.

fork, shmork.  noone fork's anymore, right?  ;-)

I'll leave it to you to decide what happens to child_exit.   I had to do this
with mod_perl so the PerlChildExitHandler will still work, the approached
seemed general enough that it might be worth doing in the core.


View raw message