in reply to Detecting Timeout of piped data

Yes, the problem is that the <> is a blocking read, which means the program is hung-up waiting for some data to arrive.

The usual way to handle this is easier than the thread mentioned by Zentara. There is an alarm that can interrupt program's execution when it counts down to zero seconds. See below for typical code. alrm_handler() is a subroutine that gets called when the alarm expires.

Note loop construction. I like to do it this way because I can see all 3 things that can cause the loop to stop all at once right there in the in the while() statement: (1) alarm, (2) no data (EOF), (3) or line text matches "DONE".

The alarm() is separated by a comma (yes, there is a comma operator). The "truth or falseness" of the of a comma joined statement is simply the last statement. This comma joined statement has the advantage that (1) no extra alarm() statement is needed before the while() statement and (2) if for some reason there are "next's" or various ways the loop can restart, I won't fail to restart the alarm (could happen if the alarm restart has to be embedded within the loop). Oh, and first thing to do within the body of the loop is to deactivate the alarm! Well unless of course the total time that you are trying to measure includes the processing time of the loop, but usually this is not the case. 

$SIG{ALRM}=\&alrm_handler;

sub alrm_handler
{
   do...something here...
   sounds like die and cause shell
   command to be re-executed...
}

my $inLine;

while (alarm(20), $inLine = <> and $inLine !~ /^Done/)
{
    alarm(0);  # deactivate the alarm!!

    normal loop here...

}
print "Exiting\n";
exit;

[download]

Replies are listed 'Best First'.
Re^2: Detecting Timeout of piped data
by sriordan (Acolyte) on Aug 01, 2011 at 20:34 UTC

    That appears to be exactly what I was looking for. I will go give that a shot. Thank you very much.

[reply]
Re^2: Detecting Timeout of piped data
by Anonymous Monk on Aug 02, 2011 at 02:36 UTC

    Does alarm actually interupt a blocking read on your systems?

    If so, could you post the versions of os and perl where this is so.

[reply]
      Sure. Tested using the below using Active State binary build 1204 (v5.12.3) built for x86_64-linux-thread-multi. This is a Fedora machine.

      For some reason, on my Windows XP, Active State v 5.10.1 build 1007 MSWin32-x86-multi-thread, the same code hangs. The alarm() appears to just disappear. Odd. There is often something special about windows. Don't know why this is happening or rather not happening at the moment, but Linux is fine.

      Update: I've seen this work on Windows before. Since both machines are running binary Active State builds, I'll retest when I get the Windows machine up to 5.12 along with the latest versions of the modules that I currently have installed. This upgrade is some months in the future... 

      #!/usr/bin/perl
use warnings;
use strict;

$SIG{ALRM} = sub { die "timeout!!! alarm\n" };

alarm(5); #start the timer

print "waiting for alarm..hit any key...";
<STDIN>;
print "waiting for another input line";
<STDIN>;
print "past the IO stuff, normal exit\n";

__END__
should see this if no key at all is hit
waiting for alarm..hit any key...timeout!!! alarm

      [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom