You mention CreateEngine but are you also creating multiple runtimes? You're only allowed 1 ScriptEngine of a given type per ScriptRuntime. So you should create a new ScriptRuntime and then get the Python engine for each runtime and then be isolated.
From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lepisto, Stephen P Sent: Thursday, April 30, 2009 8:26 AM To: users@lists.ironpython.com Subject: [IronPython] Question on Multiple Discrete IronPython sessions in a single process Hello, everyone! I am working on an service manager application that provides embedded python support through a small set of generalized classes: PythonService, PythonSession, and PythonClass. A client application asks the service manager for the PythonService object and then asks the PythonService object for a new PythonSession object. The PythonSession object is used to access embedded python through a small set of generalized methods. The PythonClass object is used to wrap a python class instance. The key requirement in this is each client must have its own python session, independent of any other sessions currently running. I've got this to work with CPython (specifically, python 2.5.4), by careful use of the global interpreter lock and swapping the thread state. IronPython 2.0.1 has a nicer way of implementing all of this by using the CreateEngine() to create a new python engine. However, in IronPython I've run into what appears to be a significant limitation that may prevent me from using IronPython in this particular situation as an embedded language. The limitation is when I import a python package from disk into IronPython (using IronPython.Hosting.Python.ImportModule()) in one session and then import the same package into a different session, it turns out that both sessions are pulling from the same module's scope. That is, if I make changes to the module's scope in one session (for example, changing a global variable), that change appears in the other session. After tracing execution in the IronPython 2.0.1 code, it turns out that a module is cached in the LanguageContext (PythonContext) object, which in turn is a singleton in DLR, as it is associated with the language type. This is okay if an application is embedding IronPython itself but in my scenario, this prevents multiple discrete python sessions in a single application. Ideally, I would expect to see the system state be stored in the python engine (ScriptEngine) or python runtime (ScriptRuntime) objects. Is there a way around this limitation? Can I somehow create a unique PythonContext object for each of my python sessions so I get a completely discrete python instance in each session with no crosstalk? Or do I have to resort to modifying the IronPython source to accomplish this (which I'm loathe to do since then I would have to maintain it going forward)? Thank you for your time and consideration in this matter.
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
