Message12908

I built myself a unit test in which each runner (thread) has its own sys instance and sys.classLoader. My Python script begins "from thin.air.Foo import *", which is a Java class that exists only as a String in the test, and gets compiled into a byte array only my special class loader class can reach. Each sys.classLoader is an insrtance of that class.

This was fun to work out, but that's another story.

In this arrangement, if you ask for thin.air.Foo via the class loader of a particular sys, you should find (as I understand it) that each gives you a distinct java.lang.Class object, and a distinct PyType must follow. This does not happen.

If I chase two threads through the import mechanism, Thread-1 manufactures JavaPackage objects in the package manager for "thin" and "thin.air". It goes via org.python.core.Py.findClassInternal, where classLoader != null, for its particular sys module, so it loads thin.air.Foo via that. It creates a PyJavaType for it (fully, under the type registry lock) and in org.python.core.PyJavaPackage.addClass(String, Class<?>) it places an entry "Foo" in the __dict__ of the PyJavaPackage for "thin.air". As it does this, Thread-1 also makes entries in sys.modules for thin and thin.air.

So far, so good.

Now, let Thread-2 try the same thing. Because it has a distinct sys, it does not find entries there made by Thread-1 in it's sys.modules (good), but each time it tries to resolve one of the elements of thin.air.Foo at org.python.core.PyJavaPackage.__findattr_ex__(String), it finds entries there, thanks to Thread-1. The outcome of this is that Thread-2 never calls its loader to load thin.air.Foo, instead finding the PyJavaType Thread-1 created.

I'm pretty sure that's not what we want.