volks,
I do hope kevin will not mind that I take back onto the list
a bit of Kvetching about 'faster, better, cheaper' - the way
hot networking code - problem. This will get way Ugly and a bit
technical so relax, get a mug of <yourBeverageDuJure> and a
big cookie and curl up around the Fire as Uncle Drieux tells
the Horror Stories about life as it evolved upwards to the
simple pair of T1's or better to bid....
On Tuesday, May 14, 2002, at 08:39 , Kevin Old wrote:
[..]
> I have this:
>
> open(PIPE1, "streaming stuff....");
> open(PIPE2, "streaming stuff....");
>
> while(<PIPE1>) {
> #write to file1.txt
> }
> while(<PIPE2>) {
> #write to file2.txt
> }
>
> This makes PIPE2 wait for PIPE1 to finish writing to file1.txt before it
> writes anything to file2.txt for PIPE2's data.
>
> I want these files to be writing data at the same time.....any ideas?
[..]
welcome to the wonder of 'network programming'.
from the perldoc -f select you will find:
"If you want to select on many filehandles you
might wish to write a subroutine:
sub fhbits {
my(@fhlist) = split(' ',$_[0]);
my($bits);
for (@fhlist) {
vec($bits,fileno($_),1) = 1;
}
$bits;
}
$rin = fhbits('STDIN TTY SOCK');
The usual idiom is:
($nfound,$timeleft) =
select($rout=$rin, $wout=$win, $eout=$ein, $timeout);"
Note: I do not trust $timeout tricks, and prefer to do the
sig_alarm tricks of setting my own alarm to break out of a
select() - that way I know it was moi that unblocked us...
But even still that would mean coming back from the select()
and then associating the the incoming file handle with the
file handle of the outgoing stream....
Assume on the other hand that you wrote one piece of code
that did the single loop on a single socket connection, and
were running the two of them... the only delay that you
would have would be the delay that 'sched' - PID 0 - gave
your two processes as they did access to the CPU......
Again, they are still in competition with each other. It is
just that they do not seem to be - unless one knows how
multi-process OS's actually handle having one CPU.
{ Hey Thread Dweezels - and we put them all back into the
same code - and have the threads in competition.... ByteMoi. }
If you were to shift to a 4-CPU machine - then it would not
be the CPU that would be your bind - since in theory at least
if you did the configs right, and the priority schema, you could
lock job_A on one CPU, lock job_B on the Other, and leave one
for sched to swap in and out of a CPU and the forth for other
processes to run.
At which point your bind will show up at the disk write or
network read side ... you can get around the disk write problem
by having multiple raid controller cards..... which brings us
down to the network read side of the problem.....
{ but what about the board level problem here? well we assumed
that you got rid of that junk dead technology of etching wire
on sand and moved on to the all optical bus, and were moving
at light speed with channelization to the controllers based
upon lambda fragmentation....}
Granted if you are running this on a T1 line - you know the
speed is pathetic - so it's time to shift your end of the
process up to a T3 or better network feed and look at doing
stripped networking reads - but that then simply moves the
bind out to the webSites you are trying to read from, especially
if they are on only t1 lines....
{ and yes kiddies - this does mean doing Optical from the
FOP to your box - I mean doesn't everyone have optical fibre
running from their FOP to their box - or are you all stuck in
that dead end ethernet technology - like so 80's.... }
Gee how do we get around that.... well if your code was really
smart it would have supported something like the PPCS { pooling
point control system } that was central to Enron's Bandwidth
market - and it would be able to do arbitrage with them to
get more bandwidth up at the far end - plus the obligatory
out of band control system to re-rig all the SONET/SDH switches
between you to cope with the striping issue.
But how does my code upgrade the internal networking problems
at these remote sites to speed up the data transfer. Well
besides getting it the
Wallstreet::Digest
module and the Obligatory
Sec::Leverage
modules to reseat the members of the executive team of
the remote sites with network savy types - well, I guess
you are sorta scrawd.
Which leaves you back with doing the best you can with
the fact that the network remains the bind and that the
flop from one file handle to the next is really about
the best that you can do at this point, especially
since Enron went belly up - and in the new re-regulatory
model of economics, the SEC, et al, may take a dim
view of market leveraging by non-CarbonBasedLifeForms.
Now if you were to support the
Net::SentientLifeForms::Rights
initiative, then your software and our software would
be able to establish a more 'culturally diverse' government
capable and willing to deal with the rights of the
FibreOpticallyEnabled ...
ciao
drieux
---
"you know that many brands of decaf
are just as good as the regular...."
- Real Genius
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
