Johan Corveleyn wrote on Sun, 20 Dec 2020 23:05 +0100:
> On Sat, May 23, 2020 at 2:17 PM Yasuhito FUTATSUKI <futatuki_at_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 :)
Received on 2020-12-21 07:50:39 CET