[IronPython] Are two PythonEngine instances connected?
dinov at exchange.microsoft.com
Tue Apr 18 20:53:37 CEST 2006
We've been discussing this internally and we believe we actually have the right solution, but it's not trivial - so it looks like it'll happen in beta 7 (there's a small chance we may decide not to do it entirely still, but hopefully that won't happen).
The solution involves saving the system state in our caller context and flowing it to places that would load additional modules. But theres a lot of details that we'll need to get right to make it all work, and it may uncover a few bugs in our caller context implementation as well. So hopefully you can get along for the next month or so and we'll be able to get the work done for 1.0.
Do you want to help develop Dynamic languages on CLR?<http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kristof Wagemans
Sent: Tuesday, April 18, 2006 11:38 AM
To: 'Discussion of IronPython'
Subject: Re: [IronPython] Are two PythonEngine instances connected?
I don't think that I would really require multiple engine instances if I could use separated sessions (system states). I could keep the states around and swap them in and out as required.
One possible problem: I create a new session and run a script in it. This script triggers the execution of another script. I would then need to unplug the current session, create a new session and run the script inside it. After the second script finishes I need to put the original session back and let it finish executing. I can imagine that it would give problems to swap sessions while one was executing (although it was temporarily suspended).
Using AppDomains or multiple Threads doesn't seem like a workable solution. It would get very complex to make the data the PythonEngine needs to operate on available in the other AppDomain. As for using threads: multithreading and user interfaces don't work well together. (I would have hoped that WPF fixed this problem, but alas...)
I don't really need an immediate solution for this. I'm just experimenting now. I think that the scenario that I've outlined is an important use for IronPython: to integrate in a .NET application and extend it with programmable and flexible extra functionality.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ironpython-users