[IronPython] Question on Multiple Discrete IronPython sessions in a single process

Michael Foord 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?

Michael

> *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 
> 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 at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/




More information about the Ironpython-users mailing list