On Wed, 15 Dec 2021, 3:18 am Eric Snow, <ericsnowcurrently@gmail.com> wrote:
Hi all,

I'm still hoping to land a per-interpreter GIL for 3.11.  There is
still a decent amount of work to be done but little of it will require
solving any big problems:

* pull remaining static globals into _PyRuntimeState and PyInterpreterState
* minor updates to PEP 554
* finish up the last couple pieces of the PEP 554 implementation
* maybe publish a companion PEP about per-interpreter GIL

There are also a few decisions to be made.  I'll open a couple of
other threads to get feedback on those.  Here I'd like your thoughts
on the following:

    Do we need a PEP about per-interpreter GIL?

I haven't thought there would be much value in such a PEP.  There
doesn't seem to be any decision that needs to be made.  At best the
PEP would be an explanation of the project, where:

* the objective has gotten a lot of support (and we're working on
addressing the concerns of the few objectors)
* most of the required work is worth doing regardless (e.g. improve
runtime init/fini, eliminate static globals)
* the performance impact is likely to be a net improvement
* it is fully backward compatible and the C-API is essentially unaffected

So the value of a PEP would be in consolidating an explanation of the
project into a single document.  It seems like a poor fit for a PEP.

I think PEP 630 (Petr's summary of the improvements to extension module reloading) is a good example of such a PEP being valuable. 

Writing such a PEP also provides a place to summarise key design decisions and known limitations (e.g. do the threading module primitives work for cross-interpreter synchronisation? If not, what should be used instead? multiprocessing? Something new that is still to be defined?).

Cheers,
Nick.


(