On Tue, Jun 30, 2009 at 11:10:41AM -0700, David James wrote:
> It's not really the best idea, though, to treat result_pool and
> scratch_pool as regular pools, since they aren't regular pools. Our
> bindings would be much happier if you just stuck with a single pool
> argument, and used that pool as our result pool. If you need to create
> a subpool from your result pool to work as a scratch pool, that is no
> problem.
The result_pool and scratch_pool separation makes sense in C.
As far as I understand we'd like most APIs to behave like that.
It's a nice API. E.g. in case you are calling a function from
a loop, which produces some result, but also requires some temporary
allocations. In that case, the caller can pass a scratch pool which
is cleared after every iteration of the loop, and a result pool which
survives all iterations.
In such cases, I believe that having the function itself repeatedly
create and destroy subpools will increase memory fragmentation.
> The Python / Ruby bindings may compile, but I doubt that they will
> work properly with your function. The bindings assume that each
> function only accepts a single pool argument, so if you have multiple
> pool arguments they will likely get very confused.
It's not just Hyrum's function. Internally, many functions have already
been converted to the dual-pool style, and now it's starting to show
up in public API, too. This change has been going on for months and
you've just discovered that it causes problems for the bindings!
> You could also teach all three sets of bindings to understand the
> difference between result pools and scratch pools, but that would be a
> much bigger project.
I think this will be necessary...
> In general, it is quite confusing and hard to maintain that our SWIG
> bindings are trying to make general decisions about how to handle
> function wrapping based on the names of variables in function
> declarations. Unfortunately, the current design of our SWIG bindings
> requires this type of trickery. In the ctypes python bindings, we
> simply wrap functions "as is", so there is no need for any fancy rules
> based on variable names. This type of design, I think, is much more
> maintainable for the long term, because it allows Subversion API
> designers to write their functions any way they want without needing
> to think about how our fancy SWIG rules will interpret your changes.
If SWIG cannot keep up with the requirements we have for our API,
then maybe we should part from SWIG in the long term and use binding
mechanisms such as ctypes instead? Perl and Ruby should have similar
mechanisms to interface with C. This is an even larger amount of work
though...
Stefan
Received on 2009-06-30 20:45:47 CEST