On 5/2/07, Dino Viehland <[EMAIL PROTECTED]> 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
_______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
