apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: svn commit: r677505 - /apr/apr-util/trunk/misc/apr_reslist.c
Date Mon, 28 Jul 2008 23:44:38 GMT
On Mon, 2008-07-28 at 23:51 +0100, Joe Orton wrote:

> It does seem like existing callers could reasonably depend on the 
> existing behaviour, and that changing it would break them.

The situation is quite complicated. Tricks like the ones from mod_dbd
(or malloc()/free() container + zero sub-pool pointer) will continue to
work. But there could also be differences in behaviour depending on the
values of min, smax, hmax and ttl, which affects how things are killed.
Dunno. Should we err on the side of caution?

> So I'd say it's either a new API guarantee (can't be done in 1.3.x) or 
> it's simply an API change (can't be done in 1.x).

Is that your -1 to backporting?

> Also note the extra confusion that apr_pool_pre_cleanup_register will 
> have different behaviour in APR 1.3.0 to releases after r678139, and 
> that would affect the APR-util API.

Yeah, that's really unfortunate :-(

Going forward (1.4.x and above), we could also simply include respool
(patch sent to the list), that implements sub-pools by default and it
doesn't have a destructor, along the lines of what you explained wrt.
"design pattern". Then people can continue using reslist as is and use
respool for new stuff, without any API/ABI breakage.


View raw message