[IronPython] Question on Multiple Discrete IronPython sessions in a single process
Dino Viehland
dinov at microsoft.com
Thu Apr 30 19:14:42 CEST 2009
Ok, it's broken on 2.0.1 but not on 2.6. I've opened a 2.0.2 bug:
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239
> -----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:47 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Question on Multiple Discrete IronPython
> sessions in a single process
>
> Dino Viehland wrote:
> > And this works for me:
> >
>
> I just did the equivalent, from *inside* IronPython which may make a
> difference, with the 'os' module and got the opposite result:
>
> >>> import clr
> >>> clr.AddReference('IronPython')
> >>> from IronPython.Hosting import Python#
> >>> e1 = Python.CreateEngine()
> >>> e2 = Python.CreateEngine()
> >>>
> >>> os1 = Python.ImportModule(e1, 'os')
> >>> os2 = Python.ImportModule(e2, 'os')
> >>>
> >>> os1
> <Microsoft.Scripting.Hosting.ScriptScope object at 0x000000000000002B
> [Microsoft
> .Scripting.Hosting.ScriptScope]>
> >>> os1 is os2
> False
> >>> os1.SetVariable('foo', 'bar')
> >>> os2.GetVariable('foo')
> 'bar'
> >>>
>
>
> All the best,
>
> Michael
>
> > 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
> >
>
>
> --
> 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