When we first talked about pools, that was the design that we agreed on:
abort() when an alloc fails. svn_pool_create() should not take an argument,
but should just use default_abort all the time. (for both client and server
portions)
As you point out: APR is not built to use any behavior other than "abort on
alloc failure" (which I believe I pointed out back then, too). As a result,
we pretty much *have* to use the abort design. However, that isn't bad at
all... it works very well for us, too.
Cheers,
-g
On Mon, Oct 09, 2000 at 04:01:38PM -0500, Jim Blandy wrote:
> >From reading apr/lib/apr_pools.c, I get the impression that pools
> return zero if they can't allocate the memory you requested, unless
> you register an abort function for them to call instead.
>
> >From reading apr/tables/apr_hash.c, I get the impression that APR's
> own hash table module assumes that pool allocation always succeeds,
> and thus can't handle pools that don't have abort functions
> registered.
>
> For the Subversion filesystem library, I'd like to assume that
> allocation always succeeds. I could simply make the requirement that
> all pools must have an abort function registered, and add a new
> Subversion error code, SVN_ERR_POOL_LACKS_ABORT. But this seems kind
> of silly, since clearly everyone (well, apr/tables, at least) is
> making this same assumption anyway.
>
> I think it would be better to simply specify that the apr allocation
> calls always succeed, specify some default behavior when we run out of
> memory (the abort () function sounds fine to me), and let people
> provide their own abort function if they don't like that.
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:10 2006