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. See, Python objects are *global*. Period. No ifs, ands, or buts. 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. And, as Paul pointed out, the global interpreter lock only kills you if you're running SMP in the first place. -- --- 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.