At 11:27 AM -0500 12/30/03, Gordon Henriksen wrote: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.
Please understand the people are not specifically criticizing you--a lot of people care about the design and success of Parrot, and it valuable for everyone to hear their opinions, even if they are seeing the problems and not the solutions. It's important (psychologically) for people to be able to feel heard, and also (statistically) to find out what the community feels is important (this slice of the community, at least). Please try not to take it personally--it's just a discussion, and people are talking just as much to each other as they are to you, even if a design decision on your part sparked the discussion. I realize it can be frustrating for you, but everyone really does seem to have the same goal at heart, and we'll end up with a better product in the end if discussion is encouraged.
Also, please share specifics that you have about design decisions that others seem to disagree with. With more information on the table, the rationale will be clearer, and that will either help convince people that it really is the best design, or it will allow them to identify specific flaws--places where some bit of data may have been overlooked. And also, if you feel stumped by something, put that out there too--I think it sets a very different tone if a (seemingly questionable) design decision is one which you think is great (or as good as it can get), versus just the best which you've been able to come up with so far. This will help steer the discussion, and make it more productive.
I hope you find this feedback useful.
JEff
