Author eric.snow
Recipients M-Reimer, bsteffensmeier, corona10, eric.snow, erlendaasland, graysky, hroncok, miss-islington, ndjensen, petr.viktorin, shihai1991, uckelman, vstinner
Date 2022-01-13.18:12:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CALFfu7Cz6z1qY2bPjj7WEM3LL=XdwyGLs+WQ6WObDdoUow0StQ@mail.gmail.com>
In-reply-to <1642095113.7.0.233625691568.issue46070@roundup.psfhosted.org>
Content
> (*) I made the GC state per-interpreter: commit 7247407c35330f3f6292f1d40606b7ba6afd5700 (Nov 20, 2019)

FYI, this was done by me in an earlier comment which we ended up
reverting.  Later you basically un.reverted that.

> The bug is that a C function object (_sre.compile) is created in an interpreter, tracked by the GC list of this interpreter, and then it is destroye and untracked in another interpreter.

FWIW, at one point I had a branch that supported sharing read-only
Py_Buffer data.  When the receiving interpreter was done with it I'd
call Py_AddPendingCall() to schedule the cleanup in the "owner"
interpreter.  However, this only worked because I kept track of the
owner.  Adding that pointer to every object wouldn't be feasible but I
suppose there are other things we could do that wouldn't be super
inefficient, like don't worry about it for the main interpreter, use a
hash table (Victor's idea), borrow some of the bits of the PyObject
head to store a flag or even an index into an array (if there are only
a few interpreters), or even make the allocator per-interpreter and
then extrapolate the interpreter based on the object's address.

Regardless, it is still much simpler to make all objects per-interpreter.
History
Date User Action Args
2022-01-13 18:12:00eric.snowsetrecipients: + eric.snow, vstinner, petr.viktorin, ndjensen, hroncok, uckelman, corona10, miss-islington, shihai1991, erlendaasland, graysky, bsteffensmeier, M-Reimer
2022-01-13 18:12:00eric.snowlinkissue46070 messages
2022-01-13 18:12:00eric.snowcreate