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