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

Re: svn commit: r16211 - trunk/subversion/bindings/swig/python/svn

From: David James <james82_at_gmail.com>
Date: 2005-09-22 23:04:32 CEST

On 9/22/05, André Malo <nd@perlig.de> wrote:
> * djames@tigris.org wrote:
> > Author: djames
> > Date: Thu Sep 22 15:22:00 2005
> > New Revision: 16211
> >
> > Modified:
> > trunk/subversion/bindings/swig/python/svn/delta.py
> > trunk/subversion/bindings/swig/python/svn/fs.py
> > trunk/subversion/bindings/swig/python/svn/repos.py
> >
> > Log:
> > Update high-level Python bindings API to make all pool parameters
> > optional, and to consistently use our new automatic pool management API.
> Hmm. These changes will create a lot of pools at import time which even may
> not be used (if the caller chooses to supply its own pool).
> Furthermore, you leak memory now, because the pools are never cleared. (Or
> do I miss something magical in the swig stuff?).
Oops! Very good catch! I didn't realise that method arguments are
initialized at import time. In that case, the idiom "pool=Pool()" is
definitely to be avoided. Instead, I'll use "pool=None".

> def foo(..., pool = None):
> if pool is None:
> pool = Pool()
The SWIG bindings automatically manage pools for us if we pass in
"None" as our pool. There's no need to initialize a pool here, so I
can simply do:
 def foo(..., pool = None):

> The leaks probably need to be solved by explicitly calling pool.clear() at
> the proper places (using subpools and try: finally: may be a good choice).
Is this necessary? If you use None as your pool, the SWIG bindings
should automatically create an anonymous pool for us, which should get
destroyed automatically at the appropriate time (assuming everything
works as promised).



David James -- http://www.cs.toronto.edu/~james
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 22 23:05:22 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.