Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: local policy)
Date: Wed, 8 Oct 2014 07:56:50 +0000
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Alexey Neyman <stilor@att.net>
Cc: Subversion Development <dev@subversion.apache.org>
Subject: Re: Pool usage in Python bindings
Message-ID: <20141008075650.GB1712@tarsus.local2>
References: <2678554.1FMrfMabGH@mistral>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2678554.1FMrfMabGH@mistral>
User-Agent: Mutt/1.5.21 (2010-09-15)

Alexey Neyman wrote on Tue, Oct 07, 2014 at 17:27:09 -0700:
> I have encountered a problem with Subversion's Python bindings. For example,
> the following simple program does not work:

Which version of the bindings?  trunk?

> Am I correct in assuming that the division of a single 'pool' argument
> into distinct 'result_pool' and 'scratch_pool' is rather recent change
> and the bindings were not updated for that?

The first instances are a few years old (1.6.0 svn_wc.h has dual pools).
New instances of dual pools happen when we create an entirely new public
API, or when we rev a single-pool API (i.e., generally, a pre-1.6 API),
in which case we make the revved API use dual pools.

> Given all that, I could think of two approaches to fixing this issue.
> 
> 1. Hackish, but simple.
> 
> Change the call signature of the functions receiving one or two pool
> arguments: make them always receive a single argument for any pools
> it may have, which may be either None (meaning "use application pool"),
> a pool object (which will be used for both the result and scratch
> allocations) or a (result_pool, scratch_pool) tuple. 
> 
> This approach has two obvious drawbacks: first, it changes the
> number of arguments on the existing interfaces (but this may not
> be a bad thing, actually, given that it makes the breakage more
> explicit - rather than subtly using the scratch pool as described above).
> Second, it makes the argument lists for functions taking two pool
> arguments not match their C counterparts. E.g., svn_stream_open_readonly
> would be invoked as:
> 
>    // C
>    res = svn_stream_open_readonly(&stream, "path",
>         result_pool, scratch_pool);
> 
>    # Python
>    stream = core.svn_stream_open_readonly("path", \
>         (result_pool, scratch_pool))

You said you had two approaches, but you only list one?

Daniel
(I don't have time to digest your mail fully right now, although I get
the big picture.)