2.6, 3.0, and truly independent intepreters

[Rhamphoryncus]

On Oct 24, 2:59 pm, Glenn Linderman <gl... at nevcal.com> wrote:
> On approximately 10/24/2008 1:09 PM, came the following characters from
> the keyboard of Rhamphoryncus:
> > PyE: objects are reclassified as shareable or non-shareable, many
> > types are now only allowed to be shareable.  A module and its classes
> > become shareable with the use of a __future__ import, and their
> > shareddict uses a read-write lock for scalability.  Most other
> > shareable objects are immutable.  Each thread is run in its own
> > private monitor, and thus protected from the normal threading memory
> > module nasties.  Alas, this gives you all the semantics, but you still
> > need scalable garbage collection.. and CPython's refcounting needs the
> > GIL.
>
> Hmm.  So I think your PyE is an instance is an attempt to be more
> explicit about what I said above in PyC: PyC threads do not share data
> between threads except by explicit interfaces.  I consider your
> definitions of shared data types somewhat orthogonal to the types of
> threads, in that both PyA and PyC threads could use these new shared
> data items.

Unlike PyC, there's a *lot* shared by default (classes, modules,
function), but it requires only minimal recoding.  It's as close to
"have your cake and eat it too" as you're gonna get.


> I think/hope that you meant that "many types are now only allowed to be
> non-shareable"?  At least, I think that should be the default; they
> should be within the context of a single, independent interpreter
> instance, so other interpreters don't even know they exist, much less
> how to share them.  If so, then I understand most of the rest of your
> paragraph, and it could be a way of providing shared objects, perhaps.

There aren't multiple interpreters under my model.  You only need
one.  Instead, you create a monitor, and run a thread on it.  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.

I've no interest in *requiring* a C/C++ extension to communicate
between isolated interpreters.  Without that they're really no better
than processes.