[IronPython] Question on Multiple Discrete IronPython sessions in a single process
Curt Hagenlocher
curt at hagenlocher.org
Thu Apr 30 19:30:38 CEST 2009
If you import by executing the text "import <modname>" against the
ScriptEngine instead of using the import API, you will avoid this particular
incarnation of the bug.
On Thu, Apr 30, 2009 at 10:25 AM, Lepisto, Stephen P <
stephen.p.lepisto at intel.com> wrote:
> I voted for fixing the bug. In the meantime, I will be putting on hold the
> use of IronPython as an embedded language in my project until this is fixed
> or IronPython 2.6 is released (if I can convince my manager and team it's a
> good idea to move to python 2.6 but it will affect a lot of people).
>
> Thank you for the prompt responses!
>
>
> -----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 10:23 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Question on Multiple Discrete IronPython sessions
> in a single process
>
> 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
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090430/a9323bd4/attachment.html>
More information about the Ironpython-users
mailing list