Re: Threads and multiple interpreters
Eero Aaltonen <[email protected]>
| Newsgroups | gmane.comp.lang.jython.devel |
|---|---|
| Message-ID | <CALo3+bwCovPU5p=x-W7d8FXR72as5Y_xBu3jtmWHWOwageKpQA@mail.gmail.com> |
On Mon, Mar 5, 2018 at 9:41 PM, Jeff Allen <[email protected]> wrote: > Although this is a compelling case for the JVM, it may not seem so for > CPython. However, the same surely applies wherever a C extension loses > interpreter context for an object that transfers between threads. In fact, > such loss of context happens all the time when interpreting CPython byte > code and has to be found each time we create a PyFrame, for example, by a > call to PyThreadState_GET(), but hardly ever has the thread changed. Even > for the JVM we should not think this applies only for objects explicitly > created to represent tasks: any call-back, in fact, any invocation of a > Python-defined operation (like PyObject._add, when it leads to the dunder > add method) needs the same consideration if objects are able to be handled > by different threads. > > At first, it seems as if every PyObject must have a reference to its > owning interpreter. I think this is not the case. Since it is only the > execution of code that raises the issue, and a (Python) function or method > seems always able to find the module it belongs to, I expect only module > objects to need this reference. The places where we must resolve the > interpreter are those where we currently pick up the thread or interpreter > state by a call to runtime support. Subject to a deeper look, I think the > slow path via the module is only needed where presently there is no > ThreadState and we fall back on the "default interpreter". But in the > absence of certainty, we shouldn't have to guess. > > Hi Jeff, Having just read this, a potential counterexample came to my mind. Suppose we want to pass a PyObject Pyo from PyInterpreterState PySa to PyInterpreterState PySb. I'm not familiar with Jythons internals, but I would assume many of the things that apply to passing object between classloaders would apply here as well. If the Pyo was loaded in a common classloader, the module of Pyo would likely be loaded by that common classloader and the module would then be unusable for distinguishing PySa and PySb. Disclaimer: This is with very limited knowledge of Jython. -- Eero Aaltonen ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Jython-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jython-dev