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

Re: Question about Python bindings

From: David Glasser <glasser_at_davidglasser.net>
Date: Thu, 22 May 2008 16:24:24 -0700

On Thu, May 22, 2008 at 3:28 AM, John Peacock
<john.peacock_at_havurah-software.org> wrote:
> Branko Čibej wrote:
>>
>> It's not obvious from the code snippet above that anyone forgot to destroy
>> a hash or clear a pool -- I don't see any pool creation there, so obviously
>> there should be no pool destruction either. And the only way to destroy a
>> hash is to clear its container pool, right?
>
> That snippet is from swig/python/libsvn_swig_py/swigutil_py.c, specifically
> svn_swig_py_mergeinfo_from_dict() which is passed in a pool by the caller.
> The usage I was questioning comes from swig/include/svn_containers.swg:
>
> $1 = svn_swig_py_mergeinfo_from_dict($input, _global_pool);
>
> where the function I quoted is being passed the _global_pool (which AIUI
> only gets cleared at program's end).
>
> So if there is no way to destroy the hash apart from clearing the pool, then
> in some sense, it *is* leaking where I noticed. But as glasser pointed out,
> there is a lot of code that assumes that this isn't a problem, because an
> error during creation /usually/ means you are just going to bubble up the
> error and then tear down everything.
>
> I'm was just trying to understand the original usage and make sure that I
> wasn't copying some code that was [already] doing the wrong thing.
>
> Thank you both!

Is _global_pool really a never-cleared pool? Apparently in Python (as
I just learned yesterday from David James) _global_py_pool is some
sort of magic pool automatically created for you when you don't
provide one, so there's basically one per API call. Could this be the
same thing?

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
Received on 2008-05-23 01:24:39 CEST

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.