[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Allocating from a pool in cleanup, WAS: RE: svn commit: rev 3709 - in trunk/subversion: libsvn_wc libsvn_client

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-11-11 01:28:42 CET

"Sander Striker" <striker@apache.org> writes:

> > I don't really understand the prohibition on allocating from a pool
> > during a cleanup handler, Subversion has been doing it for some time
> > and it doesn't appear to be a problem. I've had a quick look at the
> > APR pool code and I see no obvious reason for it not to work (but I
> > may well have missed something).
>
> I can confirm that it is safe to do allocations from the pool being cleaned
> up.

Good.

> The problem is registering cleanups in a pool in the process of being
> cleaned up. Opening files, like a lot of other APR operations, registers
> a cleanup with the pool being passed in. It probably wouldn't even be that
> hard to allow registering cleanups during cleanup; I'll look into that.

Interesting. When would they run? I think they need to be inserted
into the stack, so that they run before all previously registered
cleanups.

If this turns out to be too difficult to support it would be much
better if an error was returned rather than simply making it undefined
behaviour. This is important when the cleanup makes library calls
(such as apr_xlate_open say :) where there is no documentation to say
that it is not safe to call them from a cleanup handler.
Unfortunately, apr_pool_cleanup_register doesn't have a return value,
so it may be harder to return an error than to support registering
cleanups during cleanup!

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 11 01:29:33 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.