Re: svn commit: rev 3701 - trunk/subversion/libsvn_subr

--On Saturday, November 9, 2002 2:15 AM +0000 Philip Martin
<philip@codematters.co.uk> wrote:

> Subversion is doing so in several places. What does "other
> operations" mean? Can I call apr_pool_parent_get on a pointer to
> the pool being destroyed?

Yes, the pool structure itself is valid. Other than that, you can't
really assume anything.

> Yikes! "can't assume [they] have anything in them" You mean memory
> allocated from the pool may already be invalid? That makes the
> system very hard to use :-(

No, but you don't know what cleanups have already been run. In this
case, the apr_xlate handle is already closed.

> Well, passing the parent doesn't help if the memory is invalid (see
> above) as we won't be able to look at the access baton's stored
> path. The path would need to be allocated from the parents pool.
> You don't really mean that to cleanup an allocated structure I have
> to allocate it from the parent pool?

No, because the parent cleans the child up before it cleans itself
up. So, the parent is fine (for now).

> I accept that attempting to add new cleanup handlers should fail,
> but not being able to allocate new memory is unfortunate, and not
> being able to read already allocated memory is disasterous!

You shouldn't allocate new memory from a pool which is being cleaned
up. Nor, can you register new cleanups while the cleanups are being
run. A cleanup is *very* similar to an atexit() routine - you have
to be very knowledgable about what it is doing.

I would strongly suggest switching pool_cleanup to passing the parent
pool to the svn__wc function and be done with it. Reverting the
apr_xlate commit is only going to cause us to ignore the problem when
we already have a suggested solution.

If people have been writing pool cleanups and expecting an ordering
of cleanups to be present, that's at fault. Not the cleanups
themselves. -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 9 05:46:45 2002