Re: Inexcusable BDB upgrade triple blunder

On 2/27/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> On 2/27/06, Branko Èibej <brane@xbc.nu> wrote:
>
> > So ... any bright ideas?
>
> How about the following hare-brained scheme:
>
> Have the BDB env handles and filesystem objects both store pointers to
> each other, so the first one that has a pool cleanup fire can NULL out
> the pointers that refer to it? That way the second one to fire can't
> get back to the free'd memory.

I think this is the best you can do. If you don't have some way for
the cache to tell its users that it has gone away, then the cache's
lifetime must be a superset of all its users' lifetimes. And there's
no way to get a pool that does that.

You know, this may be an argument for a new APR operation:

/* Ensure that the pool ENDURING will be freed after the pool
TRANSIENT. The two pools must have some common ancestor pool
(possibly the root pool --- is there a root pool?), and ENDURING must
be an immediate child of that ancestor pool. */
void apr_free_pool_after (apr_pool_t *enduring, apr_pool_t *transient);

Then you'd always ensure the cache pool was going to be freed after
whatever pool was containing the svn_fs_t.

It just seems like anyone trying to implement some sort of cache for
sharing is going to run into these problems.

I'm not sure whether this solution is minimal or graceful. :)
Received on Tue Feb 28 08:03:27 2006