On Sat, 21 Mar 2020 at 13:15, Stephen J. Turnbull <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > That makes a lot of sense, as a strategy for doing the work. It > should be pretty straightforward to convert the tstate argument to a > thread-local tstate.
Note that the thread locals are already there, as that's how the public API already works. The problem is what to do when that tstate *hasn't* been populated yet. PEP 311's EnsureGIL APIs try to help with that problem, but they assume there's only one interpreter, and implicitly create a new tstate if one doesn't already exist. The APIs that now accept an explicit tstate don't care, as you can acquire that tstate from anywhere, it doesn't need to already be active on the current thread. The main working PEP at the moment is PEP 554, but the overall project tying everything together is written up at https://github.com/ericsnowcurrently/multi-core-python > But ... this sounds to me like work that should be done on a branch. The initial PEP 432 work to clean up interpreter initialisation did live on a branch for a couple of years. The problem was that we kept finding *bugs* and other behaviour problems that needed those architectural changes to properly resolve (like Victor's PEP 540 "UTF-8 mode"), as well an inability to properly *test* that we hadn't broken anything without exposing the revised architecture to the full complexity of CPython's real world use cases. Thus the original switch to the "in-tree private API" approach as described in https://www.python.org/dev/peps/pep-0432/#implementation-strategy which ultimately lead to the public initialisation API changes in PEP 587 (and the original 3.7.0 release *did* identify previously untested embedding use cases that broke in 3.7.0 and were fixed in 3.7.1). For PEP 554, the proposed public "interpreters" module is out of tree, but the low level changes to fix assorted bugs in interpreter finalization and the existing subinterpreter support is happening in-tree. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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/XNKTOTKUFYCQI5VRKSG54SFVU74Y7X6I/ Code of Conduct: http://python.org/psf/codeofconduct/
