httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: register_hooks problem
Date Wed, 17 Jan 2001 21:25:23 GMT
On Wed, Jan 17, 2001 at 01:05:51AM -0600, William A. Rowe, Jr. wrote:
> While I'm not certain of every reason, it's pretty obvious that
> dav and dav_fs are unloaded by the mod_so cleanup before their
> own cleanups are invoked.

I wondered about out cleanup strategy a little while back (not specifically
related to mod_dav; too bad it was found there first :-( ). Figured that the
cleanups were just independent enough that it wasn't causing a problem.
Guess not :-)

Note that the "right" thing would be to use separate pools for dynload
modules and for the other allocs/cleanups. You could then control the
cleanup more precisely (either sibling pools for the "other" pool would be a
sub-pool of the dynload pool).

> Number one - whoever decided the ap_global_hook_pool is good for
> modules was horribly wrong.  Modules can be removed.  Their own
> registered cleanups segfault.  So register_hooks grows a apr_pool_t
> arg for lifetime management (of course, it should be a cmd pool,
> since that's the pool modules are loaded into.)

Yay! I've been wanting to do this for a while, but couldn't figure out a
justification for that widespread of a change :-)

You'll see bitches about the lack of a pool in the FILTER_POOL symbol in
util_filter.c, dav/main/providers.c::dav_register_provider, and a few other
places. Basically, searching for ap_global_hook_pool will find a number of
gripes :-)

> Number two - there are no global pools.  Every pool -must- be a
> descendant of another.  So I'm picturing a pool assert in debug
> build that the pool allocated is a child of the pool in question.
> This is the only way we will ever catch -every- lifetime issue.

Seems fine.


Greg Stein,

View raw message