[IronPython] Question on Multiple Discrete IronPython sessions in a single process
fuzzyman at voidspace.org.uk
Thu Apr 30 18:08:27 CEST 2009
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?
> *From:* users-bounces at lists.ironpython.com
> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Lepisto,
> Stephen P
> *Sent:* Thursday, April 30, 2009 8:26 AM
> *To:* users at 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
> 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 at lists.ironpython.com
More information about the Ironpython-users