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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
