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.