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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4