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

[Dino Viehland]

Looks like our threads crossed.  Yep, I was using the current 2.6 branch.

I opened a bug to fix this in 2.0.2 (http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239).

Thanks for reporting this - this is a very bad bug.

> -----Original Message-----
> 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 10:10 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Question on Multiple Discrete IronPython
> sessions in a single process
> 
> Dino,
> 
> That example you provided produced the following output under
> IronPython 2.0.1:
> 
> hello
> 42
> 
> In other words, the two sessions appear to be sharing the same module
> in IronPython 2.0.1.
> 
> Are you using a later version of IronPython where this might be fixed?
> 
> 
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> Sent: Thursday, April 30, 2009 9:28 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Question on Multiple Discrete IronPython
> sessions in a single process
> 
> 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
> 
> _______________________________________________
> 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
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com