Embedding multiple interpreters

[Chris Angelico]

On Fri, Dec 6, 2013 at 6:59 PM, Garthy
<garthy_nhtyp at entropicsoftware.com> wrote:
> Hi Chris (and Michael),

Hehe. People often say that to me IRL, addressing me and my brother.
But he isn't on python-list, so you clearly mean Michael Torrie, yet
my brain still automatically thought you were addressing Michael
Angelico :)

> To allow each script to run in its own environment, with minimal chance of
> inadvertent interaction between the environments, whilst allowing each
> script the ability to stall on conditions that will be later met by another
> thread supplying the information, and to fit in with existing
> infrastructure.

Are the scripts written cooperatively, or must you isolate one from
another? If you need to isolate them for trust reasons, then there's
only one solution, and that's separate processes with completely
separate interpreters. But if you're prepared to accept that one
thread of execution is capable of mangling another's state, things are
a lot easier. You can protect against *inadvertent* interaction much
more easily than malicious interference. It may be that you can get
away with simply running multiple threads in one interpreter;
obviously that would have problems if you need more than one CPU core
between them all (hello GIL), but that would really be your first
limit. One thread could fiddle with __builtins__ or a standard module
and thus harass another thread, but you would know if that's what's
going on.

ChrisA