On Fri, Apr 17, 2020 at 1:54 PM Victor Stinner
Honestly, I don't think that we are far from being able to move the GIL lock per interpreter. But this change alone is useless, since we still have too many C extensions which are not ready for that:
Agreed. This is a big part of why I don't think we can make the GIL per-interpreter for 3.9. However, there are some things we could do to mitigate the problem if we want to aim for 3.9: * only allow the main interpreter to import extension modules that do not implement PEP 489 support + in subinterpreters it would be an ImportError * allow subinterpreters to be created either isolated (not sharing the GIL, etc.) or not isolated (sharing the GIL, etc.) + the default is "not isolated" (but only while the "interpreters" module is provisional) and users must opt in to isolated mode + this would allow extension authors to more easily check their modules for subinterpreter support, without causing excessive bug reports from users trying out subinterpreters I also am not convinced that in the next month we can work out all the possible corner cases problems that I expect will pop up once we have a per-interpreter GIL. Then again, arguably that could be addressed after the feature freeze if we think those possible issues could be sorted out in a month or two. :)
I would prefer PEP 554 to be restricted to the communication between interpreters.
Isolating subinterpreters should be out of the scope of this PEP, since it's a different problem and we cannot solve all problems in a single PEP.
Isolating interpreters isn't part of PEP 554, other than that objects are not shared between interpreters.
Not sure if a PEP is needed to isolate subinterpreters. There are already many issues and https://github.com/ericsnowcurrently/multi-core-python/ to track the work.
Agreed. I don't know that anyone had or has any intention of adding a PEP related to isolation (i.e. moving the GIL to PyInterpreterState). -eric