[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: Joe Swatosh <joe.swatosh_at_gmail.com>
Date: Fri, 23 May 2008 08:13:21 -0700

Hi John,

On Fri, May 23, 2008 at 7:42 AM, John Peacock
<john.peacock_at_havurah-software.org> wrote:
> David James wrote:
>> 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.
> All well and good but both the Perl and Ruby bindings reference
> "_global_pool" and what you cite is only implemented for Python. And why do
> the Python bindings sometimes reference "_global_pool" and "_global_py_pool"
> and other times only "_global_pool"...

Please take this with a grain of salt. I am by no means a swig
expert, and I can't begin to answer your questions about Python or
Perl, but since you mentioned Ruby I thought I'd add my bit.

I think the relevant parts for Ruby in an up-to-date wc (r31388) are

svn_types.swg lines 541-573
This seems to cause swig to declare a LOCAL variable named
_global_pool and to assign to it the apr_pool_t argument (making the
_global_pool name more than a little misleading).

svn_global.swg lines 189-200
This seems to actually declare a GLOBAL _global_pool for ruby. This
appears to get used when there is no apr_pool_t argument for the
function to use.

As I said, I am no expert and I have no references to give to support
my assumptions listed above. I've just read the code that swig
generates. The Python code may or may not do something similar.

Have a great weekend!

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-23 17:13:35 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.