I wish the threading design for parrot would look more toward successful, performant multithreaded systems,
I'm going to be really grumpy here, though it's not directed at Gordon. What *I* wish is that people who've not had any experience trying to build threaded interpreters for languages with data as heavyweight as perl's with a POSIXy "share everything" requirement that guarantee user threading problems won't crash the interpreter would stop pronouncing judgement on threading designs. It's getting really tiresome and I'm going to start getting viciously rude about it.
If you *have* experience with this sort of thing, *please* share. Otherwise stop telling me the design sucks--I *know* that already. What I don't have is a better answer, nor the ability to throw out the troublesome requirements.
If you want to help, then great. Specifics are a wonderful thing--X worked because of Y and Z, or Q didn't work because of R and/or S. Details are great, generalities are OK if details aren't available for whatever reason. If, on the other hand, you just want to snipe, then you can either have my job (I'm serious--you want it, it's yours) or shut up. Thanks.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
