Dan Sugalski wrote:
> 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.
Paul evidently disagrees with me, but I'll write a rebuttal to that
right after I finish this. ;-)
>>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... :)
Somewhere in between. Python names are scoped; Python objects are not.
Here's a trival example: given a global list "l" (and "global" in this
phrase almost always means "module global"), and the following code
fragment running in one thread
def foo():
x = 1
l.append(x)
any other threads created in that module will immediately have access to
the locally-created object "1".
Beyond that, though, given Python's introspection capabilities, it is
theoretically correct to say that all variables can be looked up by
name.
> 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)
Yup. Which is why the GIL represents a pretty good compromise, most of
the time, particularly the way it's implemented in Python.
>>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. :)
Should have added, "...and only if you're running pure Python code."
--
--- Aahz (@pobox.com)
Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista
I don't really mind a person having the last whine, but I do mind someone
else having the last self-righteous whine.
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