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

[M. David Peterson]

On 5/2/07, Dino Viehland <dinov at exchange.microsoft.com> wrote:
>
> Both you and Tony bring up a very good point.  I believe that we can solve
> the thread problem by using .NET's ExecutionContext.  I've never actually
> tried that, I just know it exists, so I'll need to look into that. That will
> cause the context to be flown to thread pool threads, newly created threads,
> and other various async points within the CLR.  One reason for its existence
> today is for security so the CLR is pretty good at making sure this always
> gets flowed (there are various ways to do operations which don't flow it,
> but they all have "Unsafe" in their name).
>
> Based upon Tony's description of I'm starting to believe the swappable
> SystemStates rather than multiple PythonEngines are the right solution -
> especially given that CPython is using a similar technique and even more so
> if ExecutionContext solves the async/threading problem.


I wonder if Joe Duffy and his work with PLINQ might be able to help solve
some of these issues (at least the issues involving the need for concurrent
operations) while at the same time provide a nice pathway to integrated and
direct support for LINQ inside of IP?  Thinking in terms of a
parallel-processing empowered IP engine taking on the role of a dispatcher,
multiple consoles could exist, each of which could be spawned in an isolated
or shared state at run time.  With nothing more than the knowledge of the
handle that made the request this same parallel-processing empowered IP
engine could do some *MIGHTY* things.

-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
http://dev.aol.com/blog/3155
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070505/f1ded467/attachment.html>