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

Dino Viehland dinov at microsoft.com
Thu Apr 30 18:27:54 CEST 2009


And this works for me:

using System;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;

class foo {
        static void Main(string[] args)
        {
            var engine = Python.CreateEngine();
            ScriptScope scope1 = engine.ImportModule("foo");
            
            var engine2 = Python.CreateEngine();
            ScriptScope scope2 = engine2.ImportModule("foo");
            
            scope1.SetVariable("foo", 42);
            object res;
            if(scope2.TryGetVariable("foo", out res)) {
                Console.WriteLine(res);
            } else {
                Console.WriteLine("no foo");
            }
        }
    }

Foo.py:
print 'hello'

Printing out:

hello
hello
no foo

> -----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
> 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/
> 
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com




More information about the Ironpython-users mailing list