Hi, On Tue, Dec 14, 2021 at 6:13 PM Eric Snow <ericsnowcurren...@gmail.com> wrote: > 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
I'm tracking remaining issues to get per-interpreter GIL at two places: * https://bugs.python.org/issue40512 * https://pythondev.readthedocs.io/subinterpreters.html I also wrote a recent summary of what has been done and what remains to be done: https://vstinner.github.io/isolate-subinterpreters.html Extract: """ There are still multiple interesting technical challenges: * bpo-39511: Per-interpreter singletons (None, True, False, etc.) * bpo-40601: Hide static types from the C API * Make pymalloc allocator compatible with subinterpreters. * Make the GIL per interpreter. Maybe even give the choice to share or not the GIL when a subinterpreter is created. * Make the _PyArg_Parser (parser_init()) function compatible with subinterpreters. Maybe use a per-interpreter array, similar solution than _PyUnicode_FromId(). * bpo-15751: Make the PyGILState API compatible with subinterpreters (issue created in 2012!) * bpo-40522: Get the current Python interpreter state from Thread Local Storage (autoTSSkey) Also, there are still many static types to convert to heap types (bpo-40077) and many extension modules to convert to the multiphase initialization API (bpo-163574). """ IMO "bpo-40601: Hide static types from the C API and "bpo-40522: Get the current Python interpreter state from Thread Local Storage" are non-trivial issues. Otherwise, they would already be solved. And these are strict pre-requires to consider have one GIL per interpreter. > * 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 The work required by subinterpreters help to cleaning up *all* Python objects at exit which helps another use case: embed Python in an application, especially load multiple instances of Python, when Python is used as a plugin. About the C API changes: until the "per GIL interpreter" feature is fully implemented, I'm not 100% sure that no C API change is needed. Obviously, I hope that no change will be needed ;-) Also some changes needed by interpreters introduces a small slowdown. I tried to measure it each time I noticed a potential slowdown. The largest slowdown was the _PyUnicode_FromId() change was added 1 nanosecond per function call if I recall correctly. Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ 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/6KERNBHC3LIEFF3GLXKPSC3NMQ37ISAF/ Code of Conduct: http://python.org/psf/codeofconduct/
