in reply to parallel process on remote machines,read results and hanle timeout of those process
In the script I have, it sets all the filehandels to non_blocking and use 'sysread' to read the output. Why use non-blocking? What about use while (<FH>) {push @results,$_;}. What is the difference?
If you go the blocking route, and the first blocking handle you attempt to read from fails to respond, you'll block forever.
Even if it eventually responds, you wasted a lot of time waiting for that machine when you could have been reading the responses from other machines that respond more quickly.
By going the non-blocking route, you will get the data from whichever machine responds quickest, as soon as it is available, and thus minimise the overall time required to gather all the data.
The downside is that you have to read, in set & small chunks, and reassemble the output yourself.
How to do the timeout for the filehandle?
Basically, you only need one timeout.
With non-blocking handles, you can fire off the commands to all the machines without waiting for any of them. You then start your timer (record the current time).
Then each time the select loop fires, because data is available, you read that data and add it to the buffer for the appropriate handle. Then you check how long the loop has been running and if it has exceeded your timeout, quit the select loop and close all your handles.
This means that the first machine you send the command to will have had very slightly longer to respond than the last, but as you didn't wait for the responses until after recording your start time, the difference will be minimal; and will actually mean that you gave most of the machines a few milliseconds longer than required. This should not be a problem.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: parallel process on remote machines,read results and hanle timeout of those process
by x12345 (Novice) on Oct 31, 2014 at 10:50 UTC | |
by BrowserUk (Patriarch) on Oct 31, 2014 at 12:55 UTC | |
by x12345 (Novice) on Oct 31, 2014 at 15:36 UTC | |
by BrowserUk (Patriarch) on Oct 31, 2014 at 15:56 UTC | |
by x12345 (Novice) on Nov 04, 2014 at 16:12 UTC |