2008/5/22 David Glasser <glasser_at_davidglasser.net>:
> 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?
That's right. When you call a Subversion function from Python, a
reference-counted pool is created. You can refer to this pool from
within SWIG typemap code using "_global_pool" or "_global_py_pool".
When all of the references to this pool have gone out of scope, the
pool is destroyed by the "__del__" method on the pool object.
for an explanation of how this stuff works.
Received on 2008-05-23 07:12:29 CEST