Subject: Re[2]: [linux-audio-dev] Article about multithreading
From: Rick Burnett (destinytech_AT_spacey.net)
Date: Tue Jun 19 2001 - 06:00:24 EEST
I guess your mail was just unclear to me :) But that's OK, I think
others might get from it what I got, at least thats my impression.
I cannot really comment on the garbage collector in perl because perl
is not a highly efficient language. Don't get me wrong, I use perl
ALOT. I use perl to make simple GUI interfaces or utilities, but
nothing hardcore. I was amazed at how slow perl was with data when I
wrote a program to apply patches to programs. At first I read in a
file, encrypted it in memory, then wrote it out again with other files
appended. I was AMAZED at how slow that was for a one meg file. So
then I just read in and then read out the file with no encryption,
lightning fast. I don't know enough about the underlying portions of
perl.
But this is totally offtopic, just out of curiousity, does anyone use
perl with Tk for programming anything?
Rick
Monday, June 18, 2001, you wrote:
JR> On Mon, 18 Jun 2001, Richard C. Burnett wrote:
>> I don't agree myself. Type checking is something you do to prevent
>> programming error BEFORE the program is used. Trying to 'back-out' of a
>> deadlock is something you do AFTER the program is compiled and run. In my
>> mind, if you get deadlocks then it is programming error and instead of
>> trying to back-out of it, you want something to help narrow down the
>> reasons and conditions that caused it, not fix itself taking alot of time
>> and not being made aware of it.
JR> Since I agree completely, either my mail was unclear or you
JR> misconstrued it.
JR> The original mail said that "Deadlock is really programmer error, so
JR> trying to avoid it is a really misplaced effort." My position in this
JR> conversation is that I completely disagree with that statement. In
JR> other words, you clearly want to spend effort avoiding deadlock. As
JR> Paul says, this might be through tool support such as a lock analyzer or
JR> it might be through language constructs that do not admit deadlock. Of
JR> course it can also be through disciplined and/or careful programming,
JR> and you have to be careful and disciplined anyway, if you're writing
JR> real-time systems...
>> Additionally, garbage collection is something totally different and in my
>> mind designed for people that don't really program that well. I have yet
>> to use a language in which the garbage collector worked well in many
>> situations.
JR> Perl.
JR> John Regehr
This archive was generated by hypermail 2b28 : Tue Jun 19 2001 - 05:39:40 EEST