[Python-Dev] Sandboxed Threads in Python (original) (raw)

Adam Olsen rhamph at gmail.com
Sat Oct 8 14:34:19 CEST 2005

On 10/7/05, Josiah Carlson <jcarlson at uci.edu> wrote:

Adam Olsen <rhamph at gmail.com> wrote: > I need to stress that only the new, immutable and "thread-safe > mark-and-sweep" types would be affected by these changes. Everything > else would continue to exist as it did before, and the benchmark > exists to show they can coexist without killing performance. All the benchmark showed was that checking for a constant in the refcount during in/decrefing, and not garbage collecting those objects, didn't adversely affect performance. As an aside, there's also the ugly bit about being able to guarantee that an object is immutable. I personally mutate Python strings in my C code all the time (long story, not to be discussed here), and if I can do it now, then any malicious or "inventive" person can do the same in this "sandboxed thread" Python "of the future".

Malicious use is hardly a serious concern. Someone using C code could just as well crash the interpreter.

Modifying a python string you just created before you expose it to python code should be fine. If that's not what you're doing.. I'm not sure I want to know wink

At least in the case of integers, one could work the tagged integer idea to bypass the freelist issue the Phillip offered, but in general, I don't believe there exists a truely immutable type as long as there is C extensions and/or cTypes. Further, the work to actually implement a new garbage collector for Python in order to handle these 'immutable' types seems to me to be more trouble than it is worth.

Maybe.. I'm not convinced. There's a lot of payback IMO.

-- Adam Olsen, aka Rhamphoryncus

More information about the Python-Dev mailing list