Embedding multiple interpreters

[Garthy]

Hi Gregory,

On 07/12/13 08:53, Gregory Ewing wrote:
 > Garthy wrote:
 >> The bare minimum would be protection against inadvertent interaction.
 >> Better yet would be a setup that made such interaction annoyingly
 >> difficult, and the ideal would be where it was impossible to interfere.
 >
 > To give you an idea of the kind of interference that's
 > possible, consider:
 >
 > 1) You can find all the subclasses of a given class
 > object using its __subclasses__() method.
 >
 > 2) Every class ultimately derives from class object.
 >
 > 3) All built-in class objects are shared between
 > interpreters.
 >
 > So, starting from object.__subclasses__(), code in any
 > interpreter could find any class defined by any other
 > interpreter and mutate it.

Many thanks for the excellent example. It was not clear to me how 
readily such a small and critical bit of shared state could potentially 
be abused across interpreter boundaries. I am guessing this would be the 
first in a chain of potential problems I may run into.

 > This is not something that is likely to happen by
 > accident. Whether it's "annoyingly difficult" enough
 > is something you'll have to decide.

I think it'd fall under "protection against inadvertent modification"- 
down the scale somewhat. It doesn't sound like it would be too difficult 
to achieve if the author was so inclined.

 > Also keep in mind that it's fairly easy for Python
 > code to chew up large amounts of memory and/or CPU
 > time in an uninterruptible way, e.g. by
 > evaluating 5**100000000. So even a thread that's
 > keeping its hands entirely to itself can still
 > cause trouble.

Thanks for the tip. The potential for deliberate resource exhaustion is 
unfortunately something that I am likely going to have to put up with in 
order to keep things in the same process.

Cheers,
Garth