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, just GetEngine.
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 to live. > -----Original Message----- > From: users-boun...@lists.ironpython.com [mailto:users- > boun...@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 > 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 _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com