This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.snow
Recipients aeros, eric.snow, vstinner
Date 2019-12-13.21:39:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CALFfu7DU_=Hdw76tSnzor=+OS60er+SYeWwJ1e0v=EGqW0_MjA@mail.gmail.com>
In-reply-to <1575174189.52.0.427280357232.issue37224@roundup.psfhosted.org>
Content
On Sat, Nov 30, 2019 at 9:23 PM Kyle Stanley <report@bugs.python.org> wrote:
> Based on the above hint, I was able to make some progress on a potential solution. Thanks Eric.

That's great!

> Instead of only checking "frame->f_executing", I changed "_is_running()" to also check the
> "finalizing" field of PyInterpreterState. The "finalizing" field is set to 1 in "Py_EndInterpreter()",
> so this ensures that an interpreter in the process of being destroyed is considered "running",
> so that operations (such as running scripts, destroying the interpreter, etc) can't occur during
> finalization.

Ah, that makes sense.

> I had to add a private function to the C-API in order to access "interp->finalizing" from
> Modules/_xxsubinterpretersmodule.c due to the struct for PyInterpreterState being internal only.

Yep, it has to use the public C-API just like any other module.  The
function has a "_Py" prefix and be defined in Include/cpython, right?
History
Date User Action Args
2019-12-13 21:39:20eric.snowsetrecipients: + eric.snow, vstinner, aeros
2019-12-13 21:39:20eric.snowlinkissue37224 messages
2019-12-13 21:39:19eric.snowcreate