Johan Corveleyn wrote on Sun, 20 Dec 2020 23:05 +0100: > On Sat, May 23, 2020 at 2:17 PM Yasuhito FUTATSUKI <futat...@poem.co.jp> > wrote: > > > > On 2020/05/23 12:16, Daniel Shahaf wrote: > > > Yasuhito FUTATSUKI wrote on Sat, 23 May 2020 11:08 +0900: > > >> I think it can be fixed by overriding _global_py_pool to $input in "in" > > >> typemap, when $1 is updated. It assumes that there are no APIs that > > >> uses two or more result_pool like apr_pool_t * argument for allocationg > > >> return value. > > > > > > What about svn_repos_node_editor()? It has two pools, and if I'm > > > reading the docstring correctly, "pool" will be used both for temporary > > > allocations and for allocating *editor and *edit_baton, while > > > "node_pool" will be used to allocate the tree that function constructs. > > > > > > That function is from 1.0 [according to its docstring], so it precedes > > > the result_pool/scratch_pool convention by several years. > > > > We can't add reference of "node_pool" Python object in apr_pool_t * > > members of the *editor and the *edit_baton C structure, at least > > with current wrapper mechanism. I think all we can do is to make > > "_parent_pool" attribute of wrapper objects for *editor and > > *edit_baton point to "pool" object. > > > > Fortunately as apr_pool_t *node_pool is used this API only, we can > > add typemap for it safely, in this case. > > Now that the "unable to load *.pyd files" is fixed on trunk in > r1884642 (and nominated for backport to 1.14.x), I've retried this > latest patch for fixing the refcount issue. This patch makes the > swig-python tests succeed for me (on Windows with Python 3.9.1, in > debug configuration). > > So, as far as I'm concerned, this is good to go, and certainly a step > forward again :-). > > I don't feel up to doing a proper review though, it that's what's asked here. > Can Jun or Daniel perhaps take another look?
Not this Daniel :)
