Re: [Jython-dev] Threads and multiple interpreters

[Jeff A. <ja...@fa...>]

On 19/03/2018 11:32, Eero Aaltonen wrote:
>
> 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
Too great a knowledge of actual Jython internals may be a disadvantage. 
Mine is helpfully blurred. Thanks for thinking about this.

A module source compiles to a Java class (or CPython PyCode) but the 
object in sys.modules is a PyModule instance which references the 
compiled class, and I suggest could contain a reference to an importing 
interpreter. The compiled module is a constant, while the PyModule 
contains the variable state (per interpreter I propose). We would use 
the reference upon entry to Python-aware code in that module to find the 
right sys module, codec registry, etc. and PyThread. In Jython there is 
a call to ThreadStateMapping.getThreadState and later 
ThreadStateMapping.enterCall and although that is mechanism I'm 
questioning, it is around there that this would happen.

It cannot *I think* depend on class loader identity, but needs a 
specific reference.

I didn't mention the important matter of class loaders because I don't 
quite know what I think about them. It seems likely that module 
finders/loaders are the Python idea that corresponds most closely to a 
Java class loader, in the same way that the Python and JVM threads 
correspond (but are not the same). It might be that each finder 
references a class loader. And of course each interpreter has its own 
sequence of finders, including a default one whose class loader might be 
the one that loaded the interpreter class of which it is an instance.

There is at least some coherency required between interpreters and class 
loaders, so that two applications using Jython in the same JVM work 
without interference.

Jeff