[IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released)
kristof.wagemans at gmail.com
Wed May 2 19:46:34 CEST 2007
Is the following scenario supported in v2.0?
You have a Windows MDI application with two child windows open. Each window
contains a textbox and a label. No extra threads. No extra app domains.
You enter a command in the textbox on child window 1 and send it to the
engine for execution. The output of the command is displayed in the label on
window 1. Then you do the same thing for child window 2. Is the output of
the second command displayed in the label on window 2?
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Wednesday 2 May 2007 19:17
To: Discussion of IronPython
Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond
(was IronPython 2.0 Alpha 1 Released)
Thanks for the info... Darn, it sounds like you actually want sys to be
We're going to do a review over the hosting APIs internally next week.
That should result in the last large set of changes. One thought that has
occurred to me is the ability to provide management of the current sys
instance. This is where most of the state is tracked. That would
presumably be something like allowing you to create a new system state and
provide the current system state at runtime. You could then switch system
states before running a new script code. In the multi-threaded case you
could store the system state in a thread local variable. Therefore rather
than tracking a set of engines you'd track a list of SystemState objects (or
in DLR speak they may be some opaque state object).
The one interesting thing here is how this plays w/ console output. In v2.0
that's separate from SystemState so you'd also need to update those at the
Any feedback on that proposal?
More information about the Ironpython-users