This worked fine in my first version. I change ON (which is a constant) to 1 and and slow commands like 'top' will trigger the alarm, which allows me to gracefully catch such erroneous behavior without crashing the client or the server.$SIG{ALRM} = sub { die "TIMEOUT" }; eval { alarm(ON); open COMMAND, "$command |" or die "Can't fork: $!\n"; $output .= $_ while (<COMMAND>); close COMMAND or die "Can't close pipe: $!\n"; alarm(OFF); }; if ($@ =~ /TIMEOUT/) { # do stuff }
Well, time moved on and I switched to verion 2. I decided to check my time-out code again, and this time the client would hang until I interupted the server. Hmmm, sounded like a buffering problem - but it wasn't.
Eventually I changed the above code to:
and everything went back to peachy keen (or so it seems . . .)open COMMAND, "$command |" or die "Can't fork: $!\n"; eval { alarm(ON); $output .= $_ while (<COMMAND>); alarm(OFF); }; close COMMAND; #notice no 'or die stuff' here anymore
What is bugging me is that if I use '|| die' after the close, the server indeed dies. But if I remove the close line all together, then the client will hang. I could use a warn instead of a die, but that really does me no good - the time-out will get logged by the application anyways.
If anybody can offer any insight into this, I will greatly appreciate it.
Jeff
L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
F--F--F--F--F--F--F--F--
(the triplet paradiddle)
In reply to Close the pipe before the alarm goes off! by jeffa
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |