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

Re: [PROPOSAL] Safe Memory Management for the Python/SWIG bindings

From: David James <james82_at_gmail.com>
Date: 2005-07-25 03:29:23 CEST

On 7/22/05, Mark Benedetto King <mbk@lowlatency.com> wrote:
> I know nothing of SWIG, but am a little concerned by this sort
> of GC interaction. What happens when a pool goes out-of-scope
> from Python's point of view, but references to it remain in
> datastructures in other pools?
>
> Phrased differently, how does python know whether the pool is
> still reachable?
Currently? It doesn't. It's your responsibility to keep the pool alive
by keeping it in scope. If you don't do this, Python will segfault.

I'd like to improve this situation, by keeping track of all of the
objects that were created from a pool. If we do this, the pool will
stay in scope as long as its child Python objects are still in scope.
After the pool and all of the Python-visible child objects have gone
out of scope, Python will delete the pool. Does this seem safe?

Python will only delete pools that were originally created in Python
-- we don't try to manage the C library subpools. In some cases (e.g.
callback functions), the Subversion library hands the Python
interpreter values which were created by an internal subpool. When the
internal subpool is deleted, your variables will be invalid -- but
Python won't know this. If you try to access a variable after its pool
has been deleted, Python will segfault.

I don't like segfaults. I'd like to see Python raise an exception instead.

Cheers,

David

-- 
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 Mon Jul 25 03:30:35 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.