
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.
(