+1 for consolidated documentation about per-interpreter GIL. On Tue, Dec 14, 2021 at 9:12 AM Eric Snow <ericsnowcurren...@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-le...@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/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/RK7B5NTBDRPEVKSTAF5TCL4N33RADZ5F/ Code of Conduct: http://python.org/psf/codeofconduct/
