On Tue, Oct 10, 2000 at 03:02:28AM -0400, Greg Hudson wrote:
> Can I get rid of the pool argument to svn_read_fn_t and
> svn_write_fn_t? Basically, if those functions want to do any memory
> allocation, they can store an appropriate pool in their batons, and
> they have to do that anyway if the memory has to live beyond the
> function call. (Since otherwise the output function would have no
> idea how long its pool argument is going live and the caller who
> passes the pool argument has no idea how long it needs to live.) The
> edit_fns interface doesn't pass pools around.
>
> I'm just feeling like it's a little confusing to code read and write
> functions and have two different sources of memory pools to allocate
> in. Using the wrong one would lead to difficult bugs.
I would agree with torching those.
At some point, you just have to tell callers "sorry, you just don't get that
kind of fine-grained control over my allocations." I mean really, everything
and their brother could be allocating data. No way can a caller try and
impose its requirements throughout that complexity of associations.
If a read/write function goes, "wow. I really need a lot of temporary
storage. I can't keep allocating from my own pool; otherwise, my pool would
grow into an unbounded state." The function can then be redesigned to have a
bounded size: either alloc a buffer once and drop it into its baton, or use
some kind of subpool mechanism during its read/write operation.
IOW, we have alternatives to passing those pool values. Given that we have
alternatives, and we want to trim back on the pool madness, then I'd say
torch 'em now rather than waiting for a larger consensus :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:10 2006