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

On 7/19/05, David James <james82@gmail.com> wrote:
> CHALLENGES
>
> In order for the above implementation to work, we will need to have a
> Python proxy object for every C object that is accessible from Python.
> Currently, SWIG only creates Python proxy objects if we provide it
> with the details of the internals of the C struct.
>
> Currently, we do not provide SWIG with all the details of how the
> internals of Subversion are implemented, so SWIG treats some
> Subversion datastructures as opaque pointers.
OK, I've identified the problem. So far, so good.

> We can fix this problem by using the %include directive -- just
> %include the internal .h or .c files which describe the structure.
> If we do this, then SWIG will generate real Python objects for
> our "opaque pointers" -- not just C Objects.
I've looked into this issue further. There is an easier way to ask
SWIG to setup proxy objects: just setup a dummy declaration, and tell
SWIG which functions to call in order to create and destroy objects.
Kouhei has demonstrated this technique inside core.i:

/* Dummy declaration */
struct apr_pool_t
{
};

/* Leave memory administration to ruby's GC */
%extend apr_pool_t
{
  apr_pool_t(apr_pool_t *parent=NULL, apr_allocator_t *allocator=NULL) {
    /* Disable parent pool. */
    return svn_pool_create_ex(NULL, NULL);
  }

  ~apr_pool_t() {
    apr_pool_destroy(self);
  }
};

In order for my proposal to work, we will need to use Kouhei's
technique to create Pythonic proxies for all of the SVN datatypes. If
we define a single proxy for each object inside the SWIG interface
file, SWIG will generate code in all three languages (Python, Perl,
Ruby) automatically.

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