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

Re: abort_edit in perl and python

From: John Peacock <jpeacock_at_rowman.com>
Date: 2005-03-01 13:15:56 CET

Chia-liang Kao wrote:
> a delta_editor implementation in perl or python increase refcnt for the baton
> returned by {add,open}_{file,directory}, and decreased in close.

Without looking at the code (and speaking only to the way Perl works), this
seems a little odd to me. Normally, the refcnt is incremented when more than
one reference to the /same/ object exists. So if the delta_editor has three
files to add, are you saying the same baton is used and has a refcnt of 3, or
are there three batons with a refcnt of 1?

> If the driver
> calls abort_edit at some point, those batons are leaked.

Does the abort_edit have access to the list of open batons? If so, why can't it
perform the decrement? Isn't there DESTROY method for the objects in question,
which will decrement references as the object goes out of scope?

> Actually even worse,
> the editor baton (which is the instance of the editor object) is leaked, because
> its refcnt is increased too for every add/open, I'm not sure if this is
> neccessary.

If there is a DESTROY for each object involved, this should also unwind the
editor baton refcnt.

> So my plan for rescuing the batons are to make the baton refcnt held by the
> respective file/dir pool. Or do we have a better way to make abort_edit more
> graceful in this case?

This is a great evil (hiding leaking scalars by blowing away their memory
address). It would be much better to use the normal cleanup routines and have
the object deallocate themselves when they go out of scope.

I'll try and look at the code and see if there is anything I can suggest (thus
making this less a drive-by suggestion). ;-)

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 1 13:15:17 2005

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.