![](https://secure.gravatar.com/avatar/93a1e0dae7136dd219fd23a56ca6e87b.jpg?s=120&d=mm&r=g)
On 7/15/2011 2:31 PM, Maciej Fijalkowski wrote:
I know, this is kind of hand-waving what has to be done, I would probably start with having two interpreters in one executable, probably by having two object spaces.
Cheers, fijal
And if I may ask, what are you trying to achieve?
Two (or more) interpreters in one executable. :) I was recently pondering the recent announcement by Armin that he thinks STM is the way to kill the GIL. I don't think the problem is the GIL; I think the problem is that we have only one. I think that a better (read: closer term, and more likely to be performant) answer is to create multiple interpreters, *each with their own GIL, each in their own thread,* and connect them via channels (essentially a pair of queues). I already knew about multiple object spaces and PyPy's sandboxing; I thought this would be the easiest way to play with that idea. Note that this is not Erlang-style processes - this is closer to appdomains (from .net), although the communications is inspired by Erlang+Go.