Author eric.snow
Recipients eric.snow, jeremy.kloth, jkloth, nanjekyejoannah, ncoghlan, rhettinger, vstinner
Date 2020-02-04.15:55:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CALFfu7ABKdc2NBqsMR9GMbiwKO7pHmcZFq=8gOaRiLjEW-fODg@mail.gmail.com>
In-reply-to <1580680381.65.0.617291134859.issue39511@roundup.psfhosted.org>
Content
On Sun, Feb 2, 2020 at 2:53 PM Raymond Hettinger <report@bugs.python.org> wrote:
> Is the sub-interpreter PEP approved?

PEP 554 is not approved yet (and certainly is not guaranteed, though
I'm hopeful).  However, that PEP is exclusively about exposing
subinterpreters in the stdlib.

There is no PEP for the effort to isolate subinterpreters and stop
sharing the GIL between them.  We are not planning on having such a
PEP since the actual proposal is so basic ("make the GIL
per-interpreter") and there has been no controversy.

I need to do a better job about communicating the difference, as folks
keep conflating PEP 554 with the effort to stop sharing the GIL
between subinterpreters.  Note that both are part of my "multi-core
Python" project. [1]

> If not, I had thought the plan was to only
> implement PRs that made clean-ups that would have been necessary anyway.

Right.  In this case the "cleanup" is how singletons are finalized
when the runtime shuts down.  This has a material impact on projects
that embed the CPython runtime.  Currently runtime finalization is a
mess.

That said, making the singletons per-interpreter isn't a prerequisite
of that cleanup.  For specific case of the per-interpreter GIL world,
we just need an approach that addresses their life cycle in a
thread-safe way.

[1] https://github.com/ericsnowcurrently/multi-core-python
History
Date User Action Args
2020-02-04 15:55:41eric.snowsetrecipients: + eric.snow, rhettinger, ncoghlan, vstinner, jkloth, jeremy.kloth, nanjekyejoannah
2020-02-04 15:55:41eric.snowlinkissue39511 messages
2020-02-04 15:55:41eric.snowcreate