Title: No way to get a complete unique PySystemState object for concurrent environments
Type: behaviour Severity: urgent
Components: Core Versions: 25rc4
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: Nosy List: fisherja, zyasoft
Priority: normal Keywords:

Created on 2009-05-06.21:39:39 by fisherja, last changed 2009-05-11.19:25:45 by zyasoft.

msg4648 (view) Author: Jake fisher (fisherja) Date: 2009-05-06.21:39:37
There is no way to get a complete unique PySystemState object such that
we can have separate concurrent sets of modules/packages etc running at
once. The initialize methods are mostly statics that assume Base
Properties, cache directories, etc are shareable and not per SystemState
specific. For one Jython.jar then we don't have a way to run multiple
concurrent JythonInterpreters with their own SystemStates safely as the
PySystemState shares to many static fields and methods. Also from a
perspective of managing state it would be great to have more accessor
methods available for reloading and updating modules etc.

We are currently using Jython integrated in an Eclipse RCP application
where we require a individual separate System State for each project.
This is so that we can have multiple versions of modules etc and java
packages that are per Project specific. We were sort of able to
accomplish what we need using the current implementation as far as
modules go but there are is no way to override / add other properties in
particular we need a separate cache directory for each project.
msg4649 (view) Author: Jake fisher (fisherja) Date: 2009-05-06.22:25:52
Also it would be great to not compile classes to the same directory as
the .py file
msg4661 (view) Author: Jim Baker (zyasoft) Date: 2009-05-08.18:59:20
Have you tried using PySystemState#shadow? This is for the purpose of
working around the use of statics, specifically builtins, warnoptions,
and platform. (Unfortunately we won't be able to make breaking API
changes in modules like PySystemState until 3.x.)

PySystemState.modules is an instance variable, so that should also work
for you.

You can see a moderate exercise of this is in,
specifically the test case ShadowingTest.

Note that this bug is related to #471481, #1868602, and #607391.
msg4670 (view) Author: Jim Baker (zyasoft) Date: 2009-05-10.20:08:49
Changing to pending, since this issue should have been resolved by
earlier fixes re shadowing and correct instantiation of PySystemState,
as explained in my last message.

However, this issue is complex enough that we definitely want to know if
that's the case for this particular usage.
msg4672 (view) Author: Jim Baker (zyasoft) Date: 2009-05-11.19:25:43
Closing until further notice.
Date User Action Args
2009-05-11 19:25:45zyasoftsetstatus: pending -> closed
messages: + msg4672
2009-05-10 20:08:50zyasoftsetstatus: open -> pending
priority: normal
resolution: works for me
messages: + msg4670
2009-05-08 18:59:21zyasoftsetnosy: + zyasoft
messages: + msg4661
2009-05-06 22:25:52fisherjasetmessages: + msg4649
2009-05-06 21:40:46fisherjasettitle: PySystemState does provide constructor to pass its own local postProperties -> No way to get a complete unique PySystemState object for concurrent environments
2009-05-06 21:39:39fisherjacreate