[IronPython] Question on Multiple Discrete IronPython sessions in a single process
dinov at microsoft.com
Thu Apr 30 18:19:04 CEST 2009
Oh, Python.CreateEngine will give you independent engines as it'll
create a new runtime each time. I was thinking this was one of the
normal DLR hosting APIs but I guess there is no create engine there,
Stephen, do you have a small simple repro for this? If you're using
Python.CreateEngine it should just work. The PythonContext is one
to one w/ the ScriptEngine so it's the right spot for the state
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Thursday, April 30, 2009 9:08 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Question on Multiple Discrete IronPython
> sessions in a single process
> 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
> 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
> > 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
> > this to work with CPython (specifically, python 2.5.4), by careful
> > 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
> > 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
> > 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
> > session.
> > After tracing execution in the IronPython 2.0.1 code, it turns out
> > that a module is cached in the LanguageContext (PythonContext)
> > 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
> > 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
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> Users mailing list
> Users at lists.ironpython.com
More information about the Ironpython-users