Thanks for explaining that, Ronald. It sounds like a lot of the effort would relate to making classes work. I have some comments in-line below.
-eric On Tue, Apr 21, 2020 at 2:34 AM Ronald Oussoren <ronaldousso...@mac.com> wrote: > > On 21 Apr 2020, at 03:21, Eric Snow <ericsnowcurren...@gmail.com> wrote: > > Honest question: how many C extensions have process-global state that > > will cause problems under subinterpreters? In other words, how many > > already break in mod_wsgi? > > Fully supporting sub-interpreters in PyObjC will likely be a lot of work, > mostly > due to being able to subclass Objective-C classes from Python. With sub- > interpreters a Python script in an interpreter could see an Objective-C class > in > a different sub-interpreter. The current PyObjC architecture assumes that > there’s exactly one (sub-)interpreter, that’s probably fixable but is far > from trivial. Are the Objective-C classes immutable? Are the wrappers stateful at all? Without context I'm not clear on how you would be impacted by operation under subinterpreters (i.e. PEP 554), but it sounds like the classes do have global state that is in fact interpreter-specific. I expect you would also be impacted by subinterpreters not sharing the GIL but that is a separate matter (see below). Regardless, I expect there are others in a similar situation. It would be good to understand your use case and help with a solution. Is there a specific example you can point to of code that would be problematic under subinterpreters? > With the current API it might not even be possible to add sub-interpreter > support What additional API would be needed? > (although I write this without having read the PEP). Currently PEP 554 does not talk about how to make extension modules compatible with subinterpreters. That may be worth doing, though it would definitely have to happen in the docs and (to an extent) the 3.9 "What's New" page. There is already some discussion on what should be in those docs (see https://github.com/ericsnowcurrently/multi-core-python/issues/53). Note that, until the GIL becomes per-interpreter, sharing objects isn't a problem. We were not planning on having a PEP for the stop-sharing-the-GIL effort, but I'm starting to think that it may be worth it, to cover the impact on extension modules (e.g. mitigations). So if you leave out the complications due to not sharing the GIL, the main problem extension authors face with subinterpreters (exposed by PEP 554) is when their module has process-global state that breaks under subinterpreters. From your description above, it sounds like you may be in that situation. > As far as I understand proper support for subinterpreters also requires moving > away from static type definitions to avoid sharing objects between > interpreters > (that is, use the PyType_FromSpec to build types). Correct, though that is not technically a problem until we stop sharing the GIL. > At first glance this API does not support everything I do in PyObjC (fun with > metaclasses, in C code). What specific additions/changes would you need? _______________________________________________ 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/UIX7FM2UJUL2UIIBNOBYNP42O6RCSJME/ Code of Conduct: http://python.org/psf/codeofconduct/
