+1 for consolidated documentation about per-interpreter GIL.

On Tue, Dec 14, 2021 at 9:12 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:

Even if there's no decision to be made, I think an informational PEP
would be valuable. Maybe even a Standards Track PEP? (since it
is technically a new feature)
 

* the objective has gotten a lot of support (and we're working on
addressing the concerns of the few objectors)
There's value in documenting the concerns and how they are being
addressed, and a PEP sounds like a good place to capture that.
 
* 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
Also worth documenting that in the PEP (once there are benchmarks results).
 
* it is fully backward compatible and the C-API is essentially unaffected
Since this is a likely concern, a PEP is a good place to address it.
 

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.

There is value in consolidating the project rationale, details, objections, etc.
Is it a poor fit for a PEP? I don't know - is there a better alternative?
I guess it could be covered in the docs or devguide instead,
but I don't see a philosophical issue with using a PEP for this.
 

(You might wonder, "what about PEP 554?"  I purposefully avoided any
discussion of the GIL in PEP 554.  It's purpose is to expose
subinterpreters to Python code.)

However, perhaps I'm too close to it all.  I'd like your thoughts on the matter.

Thanks!

-eric
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PNLBJBNIQDMG2YYGPBCTGOKOAVXRBJWY/
Code of Conduct: http://python.org/psf/codeofconduct/