D4118: index: make node tree a Python object
martinvonz (Martin von Zweigbergk)
phabricator at mercurial-scm.org
Wed Aug 8 20:09:49 EDT 2018
martinvonz added a comment.
In https://phab.mercurial-scm.org/D4118#64261, @yuja wrote:
> Can you bump the cext version as this patch introduces new API?
Done. Thanks for the reminder.
>
>
>> +static int nt_init_py(nodetree *self, PyObject *args)
>> +{
>> + PyObject *index;
>> + unsigned capacity;
>> + if (!PyArg_ParseTuple(args, "OI", &index, &capacity))
>> + return -1;
>
> It leaves self->nodes uninitialized on error, and nt_dealloc() would fail if
> self->nodes wasn't luckily 0. Strictly speaking, it's too late to initialize
> pointers in tp_init because __init__() may be called more than once, but our
> C types don't handle such cases.
I think the default tp_new clears the memory of the object, so it won't be uninitialized (maybe that's what you mean by "luckily", but I first thought your meant it would require luck for it to be set to 0). The only reason I think that might be the case is that we haven't seen any failures because of uninitialized memory in `index->nt` before (which used to be `index->nodes`). So I don't think we need to do anything about this. Let me know if you think we should change something.
>
>
>> + return nt_init(self, (indexObject*)index, capacity);
>
> We'll probably need INCREF/DECREF business for the index object.
Yes, I had meant to do that but then forgot, so thanks for reminding me. Done.
> I didn't review the other refcounting thingy carefully. Since it's painful
> to do refcounting right, an internal nodetree could be embedded in the
> indexObject, and a thin PyObject wrapper could be added. Just an idea.
Do you mean the refcounting of the nodetree? Assuming that the previous calls to `free()` (which I changed to `PyMem_Free()`) were correct, shouldn't it still be correct after replacing those by `nt_dealloc()`?
REPOSITORY
rHG Mercurial
REVISION DETAIL
https://phab.mercurial-scm.org/D4118
To: martinvonz, #hg-reviewers
Cc: yuja, mercurial-devel
More information about the Mercurial-devel
mailing list