Dino Viehland wrote:
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.
If you call Python.CreateEngine() twice it gives you two different
engine objects with what *appear* to be different runtimes.
If you then call Python.ImportModule for the same module but passing in
the two different engines, you get two different (non-identical objects)
ScriptScopes - but changes in one are reflected in the other.
Is CreateEngine not the correct way to get isolated engines?
Michael
*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
--
http://www.ironpythoninaction.com/
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
