[Python-Dev] Sandboxed Threads in Python

[Adam Olsen]

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