[IronPython] Question on Multiple Discrete IronPython sessions in a single process
Lepisto, Stephen P
stephen.p.lepisto at intel.com
Thu Apr 30 19:53:16 CEST 2009
Curt, thanks for the tip. In my tests, I needed to use "from <modname> import *" since I needed the attributes in the module to be in the current scope.
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher
Sent: Thursday, April 30, 2009 10:31 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process
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<mailto: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> [mailto: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> [mailto:users-<mailto:users->
> bounces at lists.ironpython.com<mailto: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> [mailto:users-<mailto:users->
> bounces at lists.ironpython.com<mailto: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> [mailto:users-<mailto:users->
> > bounces at lists.ironpython.com<mailto: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>
> > > [mailto: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<mailto: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<mailto: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<mailto:Users at lists.ironpython.com>
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto: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/27c7a7ca/attachment.html>
More information about the Ironpython-users
mailing list