2.6, 3.0, and truly independent intepreters

Rhamphoryncus rhamph at gmail.com
Sun Oct 26 00:22:49 CEST 2008

On Oct 25, 12:29 am, greg <g... at cosc.canterbury.ac.nz> wrote:
> Rhamphoryncus wrote:
> > A list
> > is not shareable, so it can only be used within the monitor it's
> > created within, but the list type object is shareable.
> Type objects contain dicts, which allow arbitrary values
> to be stored in them. What happens if one thread puts
> a private object in there? It becomes visible to other
> threads using the same type object. If it's not safe
> for sharing, bad things happen.
> Python's data model is not conducive to making a clear
> distinction between "private" and "shared" objects,
> except at the level of an entire interpreter.

shareable type objects (enabled by a __future__ import) use a
shareddict, which requires all keys and values to themselves be
shareable objects.

Although it's a significant semantic change, in many cases it's easy
to deal with: replace mutable (unshareable) global constants with
immutable ones (ie list -> tuple, set -> frozenset).  If you've got
some global state you move it into a monitor (which doesn't scale, but
that's your design).  The only time this really fails is when you're
deliberately storing arbitrary mutable objects from any thread, and
later inspecting them from any other thread (such as our new ABC
system's cache).  If you want to store an object, but only to give it
back to the original thread, I've got a way to do that.

More information about the Python-list mailing list