apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@xbc.nu>
Subject Re: On to APR 2.0.0? Beyond 9x/ME
Date Mon, 16 Feb 2009 01:52:51 GMT
Graham Leggett wrote:
> Branko Čibej wrote:
>
>> I think there may be some interest in this ... we've learned the hard
>> way that pools as they stand today, while moderately nice for stateless
>> server implementations, are less than moderately horrible for
>> anything else.
>
> I strongly disagree.
>
> malloc and free are painful in the extreme, subpools give you all the
> structure of object oriented programming, without the need to touch C++.

I'm quite mystified ... what does memory mangement have to do with OOP?
Or specifically with C++?

> Just replace malloc with apr_pool_create, and replace free with
> apr_pool_destroy, and you are done.

All right, I'll have to expand on that story it seems. But first --
using pool-create/destroy instead of malloc/free is nonsense, as the
former are quite a bit more expensive in that case, and wouldn't have
solved the problem I'm about to describe.

But I digress.

The problem I was refering to was about controlling pool lifetime in a
long-lived process-wide cache where the controlling code happened to be
in a DSO. (It's the DB_REGISTER hack in Subversion, details are in SVN
archives).

What happened was that the "global" pool that the cache was allocated
from was destroyed /after/ the DSO was unloaded, leaving cleanup
functions pointing to non-existent code. While eventually we managed to
work around that problem, it would've been a lot easier if control over
pool lifetimes were more explicit.

I expect that with the new detached global pools in APR, that particular
problem would never have arisen.

The fact remains that control of pool lifetimes, whether in combination
with DSO or long-lived memory structures, is a tricky problem not
addressed by the current implementation.

-- Brane

Mime
View raw message