Threading design
Gordon Henriksen
successful, performant multithreaded systems, rather than setting up new
design experiments based upon the results of failed experiments (in
particular, all forms of Perl 5 threading). I think that
environment-cloning and fine-grained locks have both been adequately
proven antithetical to what is expected from threads: Lightweight,
low-overhead concurrency. Environment cloning is high-performance, but
high overhead. Fine-grained locks are low overhead, but low-performance.
—
Gordon Henriksen
mali...@mac.com
Dan Sugalski
>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
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Jeff Clites
> 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
Uri Guttman
DS> I'm going to be really grumpy here, though it's not directed at
DS> Gordon. What *I* wish is that people who've not had any experience
DS> trying to build threaded interpreters for languages with data as
DS> heavyweight as perl's with a POSIXy "share everything" requirement
DS> that guarantee user threading problems won't crash the interpreter
DS> would stop pronouncing judgement on threading designs. It's
DS> getting really tiresome and I'm going to start getting viciously
DS> rude about it.
just don't start to pluck your (or parrot's) feathers. :)
lightening things a little i hope,
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org