child_exit

[Doug MacEachern <do...@telebusiness.co.nz>]

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?).  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().
I've done this with mod_perl and it seems to work just fine.

-Doug

Re: child_exit

[Doug MacEachern <do...@telebusiness.co.nz>]

Dean Gaudet wrote:

> On Tue, 17 Mar 1998, Doug MacEachern wrote:
>
> > 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.
>
> Huh?  There shouldn't be any difference between the two approaches --
> except in the ordering of the cleanups.  child_exit_modules() happens
> before the cleanups.  What were you having problems with?

no problems.  I'm pretending that child_exit is going away.  So now I have
mod_perl's child_init register a cleanup to run PerlChildExitHandlers.  If the
core's child_init registered a cleanup to run child_exit_modules(), a module's
child_exit hook wouldn't need to change, right?  This would then be the one time
and place where child_exit_modules() is called.  I'm not 100% clear on what the
current child_exit problem(s) are, so if what I'm suggesting might be bogus.

> At any rate I'm not taking it out unless someone else votes on it.  Either
> nobody cares, or nobody has noticed that I put it into the STATUS... ditto
> for the content_language thing.

I noticed the STATUS, that's why I started this thread :-)

-Doug

Re: child_exit

[Rasmus Lerdorf <ra...@lerdorf.on.ca>]

> > 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.
> 
> Huh?  There shouldn't be any difference between the two approaches --
> except in the ordering of the cleanups.  child_exit_modules() happens
> before the cleanups.  What were you having problems with? 

I don't quite understand this either.  You should be able to revert to the
register_cleanup approach now.  If we leave in the child_exit for a while
but with a little note saying it will be deprecated and for module authors
to use register_cleanup instead, then by the time we remove it nothing
should break.  Using register_cleanup is backward compatible so making
that switch at any time shouldn't be an issue.

-Rasmus

Re: child_exit

[Dean Gaudet <dg...@arctic.org>]

On Tue, 17 Mar 1998, Doug MacEachern wrote:

> 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.

Huh?  There shouldn't be any difference between the two approaches --
except in the ordering of the cleanups.  child_exit_modules() happens
before the cleanups.  What were you having problems with? 

At any rate I'm not taking it out unless someone else votes on it.  Either
nobody cares, or nobody has noticed that I put it into the STATUS... ditto
for the content_language thing.

Dean

Re: child_exit

[Doug MacEachern <do...@telebusiness.co.nz>]

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
least.

> 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.

-Doug

Re: child_exit

[Dean Gaudet <dg...@arctic.org>]

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 :)

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

What is awkward about register_cleanup()? 

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.

Dean

> I've done this with mod_perl and it seems to work just fine.
> 
> -Doug
> 
>