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

Re: svn commit: r17232 - branches/svndiff1/subversion/libsvn_delta

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2005-11-07 19:54:56 CET

On Mon, 2005-11-07 at 18:17 +0000, Philip Martin wrote:
> Daniel Berlin <dberlin@dberlin.org> writes:
> > On Mon, 2005-11-07 at 17:54 +0000, Philip Martin wrote:
> >> The err variable was present before your change, but I'm not sure why
> >> it exists. Is there some reason that the statements that set err, the
> >> calls to svn_stream_write, don't use SVN_ERR? Perhaps it's important
> >> that the svn_destroy_pool line at the end of the function gets
> >> executed even when an error occurs? If so then your use of SVN_ERR
> >> might be wrong since it will bypass that line. There is a similar
> >> problem with the SVN_ERR that occurs near the start of the function,
> >> but that might be a bug as well.
> >
> > Hmmmmmmmmmmmmmmmmmmmm.
> > I think i'm just going to replace this with some gotos, since that seems
> > the cleanest way to ensure the pool gets destroyed, but that the correct
> > value of err is there.
> > Unless you've got a better idea.
> It's not clear to me why this pool is special. We don't usually go
> out of our way to destroy subpools on error, we rely on it happening
> when the parent pool is cleared. Can we get rid of err and use
> SVN_ERR everywhere?

It's probably not too small of a pool, and it's parent probably doesn't
die very quickly, looking at the callers.

I'd venture a guess this was done to fix excessive memory usage :).

> I don't know whether that's the right thing to
> do. Is this subpool special?

It's not special in any other way, but i'd imagine it's not going to get
cleaned up for a while :)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 7 19:56:57 2005

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