On Mon, May 4, 2020 at 11:30 AM Eric Snow <ericsnowcurrently@gmail.com> wrote:

Further feedback is welcome, though I feel like the PR is ready (or
very close to ready) for pronouncement.  Thanks again to all.

FYI, after consulting with the steering council I've decided to change
the target release to 3.10, when we expect to have per-interpreter GIL
landed.  That will help maximize the impact of the module and avoid
any confusion.  I'm undecided on releasing a 3.9-only module on PyPI.
If I do it will only be for folks to try it out early and I probably
won't advertise it much.

-eric

Eric:

Many thanks for working on this so carefully for so long. I'm happy to see the per-interpreter GIL will now be studied fully before final commitment to subinterpreters in the stdlib. I would have chipped in in those terms to the review, but others succesfully argued for "provisional" inclusion, and I was content with that.

My reason for worrying about this is that, while the C-API has been there for some time, it has not had heavy use in taxing cases AFAIK, and I think there is room for it to be incorrect. I am thinking more about Jython than CPython, but ideally they are the same structures. When I put the structures to taxing use cases on paper, they don't seem quite to work. Jython has been used in environments with thread-pools, concurrency, and multiple interpreters, and this aspect has had to be "fixed" several times.

My use cases include sharing objects between interpreters, which I know the PEP doesn't. The C-API docs acknowledge that object sharing can't be prevented, but do their best to discourage it because of the hazards around allocation. Trouble is, I think it can happen unawares. The fact that Java takes on lifecycle management suggests it shouldn't be a fundamental problem in Jython. I know from other discussion it's where many would like to end up, even in CPython.

This is all theory: I don't have even a model implementation, so I won't pontificate. However, I do have pictures, without which I find it impossible to think about this subject. I couldn't find your pictures, so share mine here (WiP):

https://the-very-slow-jython-project.readthedocs.io/en/latest/architecture/interpreter-structure.html#runtime-thread-and-interpreter-cpython

I would be interested in how you solve the problem of finding the current interpreter, discussed in the article. My preferred answer is:

https://the-very-slow-jython-project.readthedocs.io/en/latest/architecture/interpreter-structure.html#critical-structures-revisited

That's the API change I think is needed. It might not have a visible effect on the PEP, but it's worth bearing in mind the risk of exposing a thing you might shortly find you want to change.

Jeff Allen