Multiple simultaneous Python interpreters

Chermside, Michael mchermside at ingdirect.com
Wed Mar 19 16:04:36 EST 2003


White Flame (aka David Holz) writes:
> [Independence] is absolutely necessary.  Independence is crucial for the 
> ability to kill off and clean up a runaway script (ie, one that is adding 
> elements to a dictionary in an infinite loop) without taking down the 
> application or other simultaneously running scripts.

Oren writes:
> Unfortunately, the CPython implementation fo the Python language uses a 
> lot of glboal state. With the Jython implementation you can instantiate
> multiple independent interpreters. If a Java environment is acceptable
> to you it might be a solution.

But Java suffers from this problem even WORSE than Python (since its
runtime is larger and slower to launch).

If you REALLY need protection from runaway processes (aka denial of service
attacks by the code you're executing) then running in separate threads
is not sufficient (I don't quite understand why, but I keep hearing experts
say it's not possible to achieve) -- you'll need to run separate processes.
If launch time isn't a problem, then you could just run a separate Python
interpreter for each instance (in it's own process), but that doesn't
scale well if you need to handle lots of short scripts.

Or, you could do what EVERYBODY ELSE[1] does, and give up on truly reliably
protection against runaway scripts, and go with "good enough" protection
-- something which is not perfectly bulletproof, but works fairly well.
THAT is something Python (or several other solutions) can achieve.

White Flame continues:
> Plus, various interpreters should have different import functionality 
> available to them, giving various "sandbox" models.

Now THAT's a MUCH easier problem to solve... there are things which can
help you achieve that with Python.

-- Michael Chermside

[1] Now that I've said this, I'm sure someone will write in to point out
   a system which provides real protection against internal DOS attacks.
   But I can't think of one.





More information about the Python-list mailing list