[30086] in Perl-Users-Digest
Perl-Users Digest, Issue: 1329 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Mar 3 21:09:39 2008
Date: Mon, 3 Mar 2008 18:09:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 3 Mar 2008 Volume: 11 Number: 1329
Today's topics:
Re: A question about multithreading <r.ted.byers@rogers.com>
Re: Converting "’" to an Apostrophe? <hjp-usenet2@hjp.at>
Re: Converting "’" to an Apostrophe? <stoupa@practisoft.cz>
Re: Crypt::CBC vs individual cipher module differs? <wgumgfy@gmail.com>
Re: FAQ 4.53 How do I manipulate arrays of bits? <brian.d.foy@gmail.com>
Re: FAQ 4.53 How do I manipulate arrays of bits? <uri@stemsystems.com>
Re: Finding number of file from gzip'ed format <tzz@lifelogs.com>
Re: grep in file and date process <RedGrittyBrick@SpamWeary.foo>
Re: how to process each directory <rsarpi@gmail.com>
Re: Parsing natural language timestamps <ced@blv-sam-01.ca.boeing.com>
Re: php vs perl for RDBMS backend work dcruncher4@aim.com
Re: php vs perl for RDBMS backend work <jstucklex@attglobal.net>
Re: reading from stdin via pipe, buffering? xhoster@gmail.com
Re: Spreadsheet::ParseExcel - How to get certain Cells <jimsgibson@gmail.com>
Re: Threading NOT working as expected <tzz@lifelogs.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 3 Mar 2008 09:18:02 -0800 (PST)
From: Ted <r.ted.byers@rogers.com>
Subject: Re: A question about multithreading
Message-Id: <fc3968f8-f975-44f5-904f-ddc8c0c9cd5f@p73g2000hsd.googlegroups.com>
On Mar 1, 6:01=A0pm, Joost Diepenmaat <jo...@zeekat.nl> wrote:
> Ted <r.ted.by...@rogers.com> writes:
> > If I launch ONE child process in one thread, one of the four available
> > cores is nearly fully utilized (about 95% of that one core's cycles.
>
> This is ofcourse expected.
>
> > But if I launch four, the load is distributed evenly over ALL
> > available cores, but only about 5% of the processor's capacity is
> > used =A0This means that the time I have to wait for results is twnety
> > times longer than it would be if I could get the processor fully
> > utilitized! =A0WHY? =A0Might it have something to do with thread priorit=
y?
>
> Since I can't see your code, I would assume this is because of the usual
> cause: the threads are actually waiting on some external even like IO to
> finish before they can contintue.
>
> If your code is actually badly written, I would suspect your threads are
> locking each other out.
>
> > If I launch the same four child processes manually, each in its own
> > separate commandline window, then I get the processor being fully
> > utilized. =A0How do I get the same effect by launching threads or child
> > processes? =A0But this gets quite tedious very quickly when there are
> > dozens of scripts to run!
>
> So your threads aren't sharing any data and run faster as separate
> processes? use fork() instead. It may be more efficient anyway, Or show
> your code.
>
That is right. Using system 1, "cmd ..." did the trick.
All the real computing is done in stored procedures. The only
difference between one SQL script and the next is that they pass
different data to the same stored procedures.
But two questions remain. Do threads launched by a process get the
same priority as the process, or are they given lower priority. And,
one commonality in how I was launching the SQL scripts was that the
script was invoked taking the script from one file and sending the
output (from standard out) into another file. Would the threads be
sharing standard out making each other wait to output their data to
their respective files?
Thanks
Ted
------------------------------
Date: Mon, 3 Mar 2008 16:45:23 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Converting "’" to an Apostrophe?
Message-Id: <slrnfso78j.f9i.hjp-usenet2@hrunkner.hjp.at>
On 2008-03-03 01:42, Petr Vileta <stoupa@practisoft.cz> wrote:
> Uri Guttman wrote:
>>> "PV" == Petr Vileta <stoupa@practisoft.cz> writes:
>>> Hmm, but try this
>>
>>> my $string = "foo\n’\nbar";
>>> $string =~ s/’/'/g;
>>> print "$string\n";
>>> __END__
>>
> Sorry, I wrote my mess late at night ;-) The true print was to have been
>
> foo
> ’
> bar
Works for me:
samkar:~/tmp 16:43 102% cat > petr
my $string = "foo\n’\nbar";
$string =~ s/’/'/g;
print "$string\n";
__END__
samkar:~/tmp 16:43 103% /usr/bin/perl petr
foo
'
bar
samkar:~/tmp 16:43 104% /usr/bin/perl -v
This is perl, v5.6.1 built for i386-linux
hp
------------------------------
Date: Tue, 4 Mar 2008 02:31:35 +0100
From: "Petr Vileta" <stoupa@practisoft.cz>
Subject: Re: Converting "’" to an Apostrophe?
Message-Id: <fqi91h$tjh$1@ns.felk.cvut.cz>
Ilya Zakharevich wrote:
> [A complimentary Cc of this posting was sent to
> Petr Vileta
> <stoupa@practisoft.cz>], who wrote in article
> <fqflav$2n2k$1@ns.felk.cvut.cz>:
>>>> my $string = "foo\n’\nbar";
>>>> $string =~ s/’/'/g;
>>>> print "$string\n";
>>>> __END__
>
>> Sorry, I wrote my mess late at night ;-) The true print was to have
>> been
>>
>> foo
>> ’
>> bar
>>
>> In other word the substitution failed.
>
> Does not fail on mine 5.6.1. Are you sure you run it exactly as
> posted?
>
Yes, I'm sure. I have ActiveState Perl installed few years ago and maybe I
have buggy version. On my linux server is 5.6.1 too and there it print as you
wrote. I don't understand ;-)
--
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your
mail from another non-spammer site please.)
Please reply to <petr AT practisoft DOT cz>
------------------------------
Date: Mon, 3 Mar 2008 09:06:55 -0800
From: "Waylen Gumbal" <wgumgfy@gmail.com>
Subject: Re: Crypt::CBC vs individual cipher module differs?
Message-Id: <632phgF25n0g3U1@mid.individual.net>
keith@bytebrothers.co.uk wrote:
> On 3 Mar, 00:01, "Waylen Gumbal" <wgum...@gmail.com> wrote:
>> I noticed that if I use a "CBC compatible" crypt module directly, I
>> get a normal expected result. But if I use CBC with the same cipher
>> type on the same key and plaintext I get a completely different
>> result.
>>
> <snip>
>> __OUTPUT__
>> OpenSSL AES
>> [e1f461cdc00f4855b9b2c0367cd3a293]
>>
>> AES via CBC
>> [53616c7465645f5f36dd0b8d9b84e278382b8cd329f7020b545c3595c239284d37d4e3dc2d6a2fc97d375675b793b357]
>
> Without knowing exactly how those particular modules do what they do,
> the first thing that occurs to me is that nowhere are you providing an
> initialisation vector, so presumably the modules are generating a
> random IV. That will give you totally different ciphertext. The
> lengths _may_ be different because the latter attempt is prepending
> the ciphertext with the IV, which is required for decryption.
>
> Just my 2 pennyworth...
I tried using different values for the -iv parameter for CBC but I can't
seem to find a way to get the same value using the cipher module
straight does. I want them to be compatible for each other and frankly
the fact that they give completely different results seems to defy the
point of using CBC, doesn't it?
--
WG
------------------------------
Date: Mon, 03 Mar 2008 13:46:26 -0600
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: FAQ 4.53 How do I manipulate arrays of bits?
Message-Id: <030320081346262073%brian.d.foy@gmail.com>
In article
<ca334bbf-a028-4179-bcac-6fe5105b1376@13g2000hsb.googlegroups.com>,
<sheinrich@my-deja.com> wrote:
> On Feb 29, 9:03 pm, PerlFAQ Server <br...@stonehenge.com> wrote:
> <snip>
> > For example, this sets $vec to have bit N set if $ints[N] was set:
> >
> > $vec = '';
> > foreach(@ints) { vec($vec,$_,1) = 1 }
> >
> <snip>
>
> IMHO the above sentence is wrong.
Indeed it is. Thanks for noticing it. :)
Here's my replacement:
For example, you don't have to store individual bits in an array
(which would mean that you're wasting a lot of space). To convert an
array of bits to a string, use C<vec()> to set the right bits. This
sets C<$vec> to have bit N set only if C<$ints[N]> was set:
@ints = (...); # array of bits, e.g. ( 1, 0, 0, 1, 1, 0 ... )
$vec = '';
foreach(@ints) {
vec($vec,$_,1) = 1 if $_;
}
The string C<$vec> only takes up as many bits as it needs. For
instance, if you had 16 entries in C<@ints>, C<$vec> only needs two
bytes to store them (not counting the scalar variable overhead).
------------------------------
Date: Mon, 03 Mar 2008 21:12:16 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: FAQ 4.53 How do I manipulate arrays of bits?
Message-Id: <x78x0zqzpr.fsf@mail.sysarch.com>
>>>>> "bdf" == brian d foy <brian.d.foy@gmail.com> writes:
bdf> In article
bdf> <ca334bbf-a028-4179-bcac-6fe5105b1376@13g2000hsb.googlegroups.com>,
bdf> <sheinrich@my-deja.com> wrote:
>> On Feb 29, 9:03 pm, PerlFAQ Server <br...@stonehenge.com> wrote:
>> <snip>
>> > For example, this sets $vec to have bit N set if $ints[N] was set:
>> >
>> > $vec = '';
>> > foreach(@ints) { vec($vec,$_,1) = 1 }
>> >
>> <snip>
>>
>> IMHO the above sentence is wrong.
and the code is wrong too.
my @ints = ( 1, 0, 0, 1, 1, 0 ) ;
my $vec = '';
foreach(@ints) {
vec($vec,$_,1) = 1 if $_;
}
print join( '', unpack 'B*', $vec ), "\n" ;
foreach(0 .. $#ints) {
vec($vec,$_,1) = $ints[$_];
}
print join( '', unpack 'B*', $vec ), "\n" ;
output:
00000010
00011001
the FAQ loop never changes the offset arg to vec so it twiddles the same
bit over and over.
in fact given a list of bit values, pack is the best answer for making a
bit vector. vec is better for random access of bit fields (and it sucks
because of its requirement for the field size being a power of
2). Bit::Vector is a very good module (speedy since it is in XS) for all
sorts of bit stuff.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Architecture, Development, Training, Support, Code Review ------
----------- Search or Offer Perl Jobs ----- http://jobs.perl.org ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Mon, 03 Mar 2008 08:39:07 -0600
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Finding number of file from gzip'ed format
Message-Id: <86skz7eut0.fsf@lifelogs.com>
On Fri, 29 Feb 2008 11:58:05 -0800 (PST) "sopan.shewale@gmail.com" <sopan.shewale@gmail.com> wrote:
ssc> Hi,
ssc> I am not sure if this is the right group to ask this question - i am
ssc> sorry if this is not the right place.
ssc> Problem: Let us say we have file called "myfile.txt". The size of the
ssc> file is huge. The file is gziped - the gziped filename is
ssc> "myfile.txt.gz". I am interested to find the number of lines of
ssc> myfile.txt from myfile.txt.gz without gunziping it.
ssc> I know if it is allowed to gunzip then just use "gunzip -c
ssc> myfile.txt.gz | wc -l" this can give the number of lines.
ssc> My problem is time taken to gunzip is huge file is very large.
ssc> Is there any way to count the number of lines using Perl script/Any
ssc> other method - just to figure out number of "\n" chars hidden inside
ssc> the file-use something from the algorithm of gzip?
ssc> Appreciate your time efforts to read the problem and thank you so much
ssc> for investing time to read this problem.
ssc> Please help me with solution or pointers to read (already reading
ssc> http://www.gzip.org/algorithm.txt).
If the only metadata you'll need is the number of lines, just rename to
myfile.N.txt.gz where N is the number of lines. So, if there is no N
you have to count (you can't avoid that cost, because newlines are just
content), but if N is already calculated you're done. Obviously if you
modify the file you recalculate N, but a compressed file is unlikely to
be modified in place.
It's not a long-term solution and it will only work for this one piece
of data, but it's easy to implement.
The question is, why do you need to count newlines? If you specifically
need to show exact statistics about how many lines are in the file,
you're stuck. But you can at least approximate from the file size and
average bytes per line over the first 5000 lines.
Users really appreciate interactive applications. If instead of doing
the wc -l and THEN displaying it, you maintain a running counter of the
number of lines and update the screen with the new value periodically, I
guarantee you that users won't mind it much.
You could even show a progress bar using the average bytes per line so
far, or the much easier Zeno's paradox progress bar (every update adds
50% of the remainder, so you do 50%, 75%, 87.5%, etc.).
Ted
------------------------------
Date: Mon, 03 Mar 2008 14:36:19 +0000
From: RedGrittyBrick <RedGrittyBrick@SpamWeary.foo>
Subject: Re: grep in file and date process
Message-Id: <47cc0ce4$0$32047$da0feed9@news.zen.co.uk>
Mr_Noob wrote:
> On Mar 3, 1:49 pm, RedGrittyBrick <RedGrittyBr...@SpamWeary.foo>
> wrote:
>> Mr_Noob wrote:
>>> Hi all,
>>> here is an extract of my file :
>>> 2008/03/03 12:56:07 put /name_of_client4/pub/file.xml
>>> 2008/03/03 12:56:07 put /name_of_client1/pub/videos/file.mov
>>> 2008/03/03 12:56:07 put /name_of_client1/pub/videos/file.wmv
>>> 2008/03/03 12:56:07 put /name_of_client5/pub/file.xml
>>> 2008/03/03 12:56:07 put /name_of_client1/pub/videos/file.flv
>>> 2008/03/03 12:56:07 put /name_of_client1/pub/videos/file.jpg
>>> 2008/03/03 12:56:07 put /name_of_client2/pub/file.jpg
>>> 2008/03/03 12:56:07 put /name_of_client3/pub/file.xml
>>> 2008/03/03 12:56:07 put /name_of_client5/pub/file.mov
>>> 2008/03/03 12:56:07 put /name_of_client1/pub/file.xml
>>> ...
>>> What would be the best way to grep for a specified "name_of_client"
>>> then calculate the time since last file has been put ?
>>> open( FILE, "< $filename" ) or die "Can't open $filename : $!";
>>> while( <FILE> ) {
>>> # grep last appearance of specified name_of_client
>>> # time since last transfer
>> Some combination of 'next unless /name_of_client/', split, a hash and a
>> date module.
>>
>>> }
>>> close FILE;
>
> ok , but how can I tell my script to grep only the last appearance of
> a client's name for further process ?
Don't, just overwrite the hash (e.g. $lastdate{$client}=$date;). After
closing the file, loop through the hash and do there whatever processing
you had envisaged doing in your while(<FILE>) loop.
------------------------------
Date: Mon, 3 Mar 2008 17:25:55 -0800 (PST)
From: monk <rsarpi@gmail.com>
Subject: Re: how to process each directory
Message-Id: <47a94d62-f16d-4b2f-9dcb-5de0fb1e9ee9@e25g2000prg.googlegroups.com>
On Feb 27, 1:51 pm, Jim Gibson <jimsgib...@gmail.com> wrote:
> In article
> <541fc356-fc1c-4fd1-a2ea-e9ea1de6f...@s19g2000prg.googlegroups.com>,
>
>
>
> monk <rsa...@gmail.com> wrote:
> > Thanks for the tip 'od -c <filename>'
>
> > I uncovered an extra character was being added somehow when slurping
> > the config file.
> > I added one little line to my code and now it works like a charm.
>
> > foreach (@directories_to_clean){
> > chomp;
>
> > chop; # one extra line that solved my problem.
>
> > print "$_\n";
>
> > #and everything else is the same
>
> > }
>
> That is not a good, long-term solution. It is not likely that slurping
> the file is adding extra characters. It is more likely that the file
> does not have the proper line endings for your system. As soon as
> somebody edits your file with the proper editor, it may remove the
> extra characters and your program will no longer work.
>
> You should determine exactly what the extra characters are and remove
> them. chop will remove the last character of your string, regardless of
> what it is.
>
> In your original program, which you do not show, you have already used
> chomp on the lines read from your file, and the chomp shown above is a
> no-op. chomp will remove the expected line-ending character or
> characters from a string. If they are not found, chomp does nothing.
>
> Use the substitute operator or the tr operator to remove only those
> characters that do not belong:
>
> s/[\r\n]+//;
> tr/\r\n/d;
>
> --
> Jim Gibson
Jim, you're absolutely right.
So yeah, using <od -c filename> I identified the extra characters that
were added and then used regular substitution. This is a much more
efficient approach. Now I'm just removing only the ones I need. Not
just whatever was there.
thanks,
------------------------------
Date: Mon, 3 Mar 2008 12:51:06 -0800 (PST)
From: "comp.llang.perl.moderated" <ced@blv-sam-01.ca.boeing.com>
Subject: Re: Parsing natural language timestamps
Message-Id: <2fa13590-926d-4bb9-b279-561254dbfd68@d4g2000prg.googlegroups.com>
On Mar 3, 12:37 am, Peter Makholm <pe...@makholm.net> wrote:
> I have a command line application where the use specifies a time span
> with two arguments --from and --to. At the moment I'm using strptime
> from Date::Parse, but it would be nice to support dates like '2 days
> ago', 'today', 'next friday'.
>
> If the user doesn't specifies a exact time but just a day I would like
> to have the from argument use the start of the date (00:00:00) and the
> to argument use the end of the date (23:59:59).
>...
A Date::Manip concoction could help if you're say, trying to normalize
"today".
If "today" is the --from:
UnixDate(UnixDate(ParseDate("today"),"%b%e%Y")"%s)
* This gives the epoch for today=20080303 00:00:00
If "today" is the --to, use the above replacing "today" with
"tomorrow", then subtract 1 for an end-of-day epoch, ie, 20080303
23:59:59
hth,
--
Charles DeRykus
------------------------------
Date: 3 Mar 2008 08:55:14 -0800
From: dcruncher4@aim.com
Subject: Re: php vs perl for RDBMS backend work
Message-Id: <fqhahi0kqp@drn.newsguy.com>
Oh no. This is not to rewrite existing code. I want to check
whether it is worth investing on php for any new code. of course
my boss will ask me to justify why I would want php when perl
has been doing the job fine so far. I can't tell that the only
valid reason is that I want to learn php and add it in my resume (haha).
So I need some real reasons as to why php is superior to perl.
I got one so far: It has a more natural support for OO, which I agree.
thanks.
In article <o8ednQljEdyhklbanZ2dnUVZ_rvinZ2d@comcast.com>, Jerry Stuckle says...
>Both are just languages. Neither one has any particular advantage in
>maintenance, etc. It much more depends on the programmers who write the
>code, how well the code is written and commented, the skills of the
>people maintaining the code, and a bunch of other things.
>
>And if it's working now, I see no reason to invest a bunch of time and
>money rewriting it. Don't fix what isn't broke.
>
------------------------------
Date: Mon, 03 Mar 2008 13:04:40 -0500
From: Jerry Stuckle <jstucklex@attglobal.net>
Subject: Re: php vs perl for RDBMS backend work
Message-Id: <ssednRK5wvCKo1HanZ2dnUVZ_vjinZ2d@comcast.com>
dcruncher4@aim.com wrote:
> Oh no. This is not to rewrite existing code. I want to check
> whether it is worth investing on php for any new code. of course
> my boss will ask me to justify why I would want php when perl
> has been doing the job fine so far. I can't tell that the only
> valid reason is that I want to learn php and add it in my resume (haha).
>
> So I need some real reasons as to why php is superior to perl.
> I got one so far: It has a more natural support for OO, which I agree.
>
> thanks.
>
> In article <o8ednQljEdyhklbanZ2dnUVZ_rvinZ2d@comcast.com>, Jerry Stuckle says...
>> Both are just languages. Neither one has any particular advantage in
>> maintenance, etc. It much more depends on the programmers who write the
>> code, how well the code is written and commented, the skills of the
>> people maintaining the code, and a bunch of other things.
>>
>> And if it's working now, I see no reason to invest a bunch of time and
>> money rewriting it. Don't fix what isn't broke.
>>
>
>
True, but if everything else is in Perl, I would agree with your boss.
Having something in two different languages means you need twice the
skill set to maintain it.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
------------------------------
Date: 03 Mar 2008 17:08:46 GMT
From: xhoster@gmail.com
Subject: Re: reading from stdin via pipe, buffering?
Message-Id: <20080303120848.289$AL@newsreader.com>
Rudy Gevaert <Rudy.Gevaertno@spamugent.be> wrote:
> Hi,
>
> I have written a perl program that reads from stdin:
> while(<STDIN>)
> {
> chomp
> do_it($_);
> }
> Data is fed to it via a pipe:
>
> cat myfile | ./myprogram
>
> When running the program, the program doesn't always read the whole
> line. I'm guessing this has something to do with the stdin buffer.
My guess is that you are misinterpreting something. Maybe you have
cross OS line ending problems.
>
> I would like to know how I can make that perl gets the whole line. As
> it is clearly failing from time to time.
That is far from clear to me. Can you produce an example we can
run to show this problem?
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Mon, 03 Mar 2008 10:22:30 -0800
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: Spreadsheet::ParseExcel - How to get certain Cells
Message-Id: <030320081022305570%jimsgibson@gmail.com>
In article
<dca404cc-faac-4cf0-88d6-03ae5eb94918@u10g2000prn.googlegroups.com>,
ccc31807 <cartercc@gmail.com> wrote:
> I have to play with Perl and Excel from time to time, but my problem
> goes the other way -- writing to an Excel file rather than reading
> one. The crude way is writing the data to a csv file that Excel will
> open natively. This works perfectly for the data but it doesn't
> configure the workbook. The other way is to generate an xml file that
> Excel will open. This also works perfectly, it's more work for me but
> the file will also open in a browser which you can connect with a CSS
> file and pretty it up for users that only want to look at the data,
> not manipulate it. And in fact, you can do both for your two kinds of
> users, those that want to slice and dice the data and those that only
> want to look at it.
Have you considered using the module Spreadsheet::WriteExcel to write
an Excel file?
--
Jim Gibson
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
------------------------------
Date: Mon, 03 Mar 2008 13:38:12 -0600
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Threading NOT working as expected
Message-Id: <86mypfd2e3.fsf@lifelogs.com>
On Sat, 1 Mar 2008 18:09:32 +0100 Martijn Lievaart <m@rtij.nl.invlalid> wrote:
ML> On Sat, 01 Mar 2008 17:04:08 +0100, Peter J. Holzer wrote:
>> On 2008-02-26 16:39, Ted Zlatanov <tzz@lifelogs.com> wrote:
>>> In a multithreaded setup, the CPU has a chance to run several threads
>>> while memory and I/O fetches are happening.
>>
>> Multithreading won't help for memory fetches. Firstly because CPUs don't
>> have a way to inform the OS of a slow memory access, and secondly
>> because the overhead of switching to a different thread would be much
>> too high for such a (relatively) short wait. There is one exception:
>> So-called multi-threading CPUs can keep the state of a fixed (and
>> usually low) number of thrads on the CPU and switch between them. But
>> these are really just multi-core CPUs which share some of their units.
>>
>> You are completely right about I/O of course.
ML> Not even. If all those I/Os are going to the same disk, you run the risk
ML> of thrashing, and overall performance goes down instead of up.
That's very application-dependent. Note my original statement: the CPU
has a chance to run several threads while fetches are happening. It
doesn't mean that I/O will work better than way, but that's not a
multithreading problem. The elevator algorithm introduced fairly
recently in Linux kernels (IIRC) addresses this kind of I/O contention
in the right place, outside the application.
Ted
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 1329
***************************************
