[Python-Dev] Parrot -- should life imitate satire?

Dan Sugalski dan@sidhe.org
Tue, 31 Jul 2001 20:19:41 -0400


At 05:04 PM 7/31/2001 -0700, Aahz Maruch wrote:
>Dan Sugalski wrote:
> >
> > As for threading, well, that's where things get interesting. Perl's
> > tried it two ways (multiple threads in the same interpreter, and one
> > thread per interpreter, with cloned interpreters) both of which aren't
> > very good. And the global lock thing's not that keen either. The plan
> > for parrot is to allow multiple interpreters to run simultaneously,
> > with shared data protected on access time. (And *only* shared data
> > protected, so there's no penalty to access non-shared data) Along with
> > a scheme to allow only partial (or no) visibility of the spawning
> > thread's variables. We plan on basing the secure sandbox scheme around
> > this as well.
>
>This is where calling what Python uses "variables" gets you into real
>problems.  Many people think that the terms for "variable" and
>"reference" should be "name" and "binding"; it makes things far less
>confusing.

I'm not sure that's the appropriate translation for what perl considers 
variables and references, but that's OK.

>See, Python objects are *global*.  Period.  No ifs, ands, or
>buts.

Is this global in the "all variables are in one big pool and can be looked 
up by name", more or less the equivalent of externing all your C variables, 
or global in the "Any thread might be able to see it" sense? (I thought 
Python had lexically scoped variables, but I might be wrong here. I'm an 
internals guy--the actual language being run is just an implementation 
detail... :)

If it's "All objects are visible to all threads" thing, that's fine, you 
can still handle threading with some care. Perl's done it wrong once, and I 
know how to do it much less wrong with Parrot. (It's not, strictly 
speaking, possible to do it right without the programmer taking an active hand)

>Any object can be shared at any time.  More than that, most of
>the time Python threads are bound to class instances, so causing another
>thread to get a binding to an object is as simple as setting an
>attribute of that thread's instance.

Ah. Doable, and not much of a problem. It'll require tweaking the thread 
model a touch (for which I appreciate you bringing this up) but better now 
than later.

>And, as Paul pointed out, the global interpreter lock only kills you if
>you're running SMP in the first place.

Yep, well, I do. :)

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk