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

Re: Guaranteeing memory pool lifetime

From: David James <james82_at_gmail.com>
Date: 2005-07-05 15:41:52 CEST

On 05 Jul 2005 03:05:56 -0500, C. Michael Pilato <cmpilato@collab.net> wrote:
> Matthew Hambley <matthew@aether.demon.co.uk> writes:
> > As I understand the usage of memory pools in subversion all I can take for
> > granted is that the pool passed into a function will exist for the duration
> > of the call. However I want to allocate some space which persists for the
> > lifetime of the client. What pool should I use which has such a lifespan
> > and how would I access it?
> What you can take for granted is that any pool your code creates will
> not be destroyed by a Subversion API (unless the docstring for that
> API explicitly states so -- and I dunno of any that do).
Mike, Matthew, you have raised some interesting points which may
affect the SWIG bindings.

In the Ruby and Perl bindings, we automatically destroy pools when we
determine that they are no longer needed. I am hoping to also
implement this feature for Python. Is there an easy way to determine
whether a pool is OK to destroy? Currently, I am planning to destroy
pools as soon as all of the variables returned by functions which
access that pool have gone out of scope. Is this is a safe rule to
follow, in general?

Here is an example, in Ruby:
  ctx = Svn::Client::Context.new()

When you call the Svn::Client::Context.new() function, we
automatically create a pool if one does not already exist. In the
above case, only one variable (ctx) is created by functions which use
the automatic pool. We therefore assume that it is safe to delete the
automatic pool when the "ctx" variable goes out of scope.



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 Tue Jul 5 15:46:33 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.