Re: abort_edit in perl and python

On Tue, Mar 01, 2005 at 07:15:56AM -0500, John Peacock wrote:
> 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?

Three batons with a refcnt of 1, since they need to be held for
apply_textdelta or child directories.

> 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?

No, there's currently no such list maintained in the editor baton.

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

huh? it's because the svn/perl bit holds the refcnt so the editor object is
not freed and thus DESTROY is not called.

> >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.

It's not like blowing away their memory address. There's a util function
in libsvn_swig_perl to make a pool decrease refcnt of an SV upon pool
cleanup.

Cheers,
CLK

---------------------------------------------------------------------
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:31:50 2005