Le ven. 17 avr. 2020 à 20:56, Eric Snow <ericsnowcurren...@gmail.com> a écrit : > keep in mind that > subinterpreters currently have various other limitations (aside from > sharing the GIL): > > * nothing about them has been optimized (e.g. interpreter startup, > data sharing, data passing) > * extension modules with process-global state may break > * some bugs still remain in the corners
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: * C extension modules should be converted to multiphase initialization (PEP 489) * Statically allocated types should be converted to heap allocated types (PyType_FromSpec) * A module state should be added to a bunch of C extension modules * Many C extension modules don't implement the GC protocol, since it wasn't really needed previously: this should now be done (implement traverse, clear, free) * These two changes require PEP 573 to be implemented to get access the module state in functions where it wasn't possible previously The good news is that there is an on-going effort to complete this task: https://bugs.python.org/issue1635741 More and more C extension modukes are converted. The bad news is that better isolating subinterpreters "suddently" triggers old issues. See for example https://bugs.python.org/issue40217 "The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type" which is a very complex issue. I also fixed many reference cycles and other bugs, discovered after some specific C extensions were modified. There are still tons of "static" variables all around the code and still no technical solution to have "per interpreter" variable. We need something like Thread-Locale State, but for interpreters in the C API. PyInterpreter.dict is not convenient in C. Well, I'm not writing that for Eric who is already well aware of these issues, but for others ;-) > At this point I think we should go with option #1 (or possibly #2). > IMHO, we would be fine merging PEP 554 without per-interpreter GIL. 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. See what happened with PEP 432 which tried to solve multiple related problems: PEP 587 fixed the preinitialization and the configuration, but not the "path configuration" issue. Excluding the "path configuration" from the PEP 432 in the PEP 587 made possible to get a PEP "done". 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. 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/U65UDU5V64EPYHPBLQKOEU3A23ZXIBY7/ Code of Conduct: http://python.org/psf/codeofconduct/
