[IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released)

[Dino Viehland]

The scripts are running on multiple threads?  The easy way to do this in v2.0 is to set console output (we no longer maintain our own output streams) to be a stream which looks at a thread static variable which is the real stream to output to.  Would that solve the entire isolation problem for you?

The only problem w/ this is if user code sets sys.stdout they'll hijack all the other scripts.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Wednesday, May 02, 2007 5:58 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released)

Michael Foord wrote:
> Dino Viehland wrote:
>
>> I'm not actually the one working on the engine APIs so that's the reason I've tended to be vague.  I'll talk to the people doing it and let you know what I hear.
>>
>> But the more info you can give us the better decision we'll be able to make.  For example what do you actually need to be isolated?  Do you need multiple system states so they get their own modules, console, etc...  do you need everything in sys isolated?  Do you need to guarantee the isolation even if .NET code is called (e.g. they could smuggled data via a static field).  If they do need some rather high level of isolation are app domains good enough?  Do you need to marshal a lot of data in/out?  Or is the effort to spin up and use app domains correctly?
>>
>>
> At Resolver we are currently using multiple IronPython engines. Moving
> to AppDomains is a long term goal for us, but is actually quite a lot of
> work (we would have *lots* of cross-domain calls and so to avoid that we
> have to find an efficient way of pumping lots of data in and then out of
> the app domain).
>
> Switching to app domains is not a high priority task for us, and in the
> meantime we *can't* upgrade to IronPython 2 if it doesn't support
> multiple engines.
>
> Isolation of engines is only a minor benefit (it is a positive side
> effect - but not the reason we started using them) for us at the moment,
> and an isolated system state (although nice) is not vital.
>
>

In fact, the reason we started using multiple engines was to divert the
standard output of simultaneously running user scripts to different
output windows...

Michael


> All the best,
>
> Michael Foord
> http://www.voidspace.org.uk/ironpython/index.shtml
>
> _______________________________________________
> 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