Re^6: How to timeout if a call to an external program takes too long

Now I'm confused. In the second example, control was returned to the script after the 5 seconds. The external process continues, but as you say, that's a different problem,

But in the first example, whilst the signal handler was invoked after 5 seconds, the command completed ('yawn' was returned) and that did not happen until the external 10 second sleep completed?

Ie. Unless I am interpreting the output you posted incorrectly, the first example shows that the script cannot continue until the external command completes, even though the signal handler was invoked earlier than that.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re^6: How to timeout if a call to an external program takes too long

Replies are listed 'Best First'.
Re^7: How to timeout if a call to an external program takes too long by kyle (Abbot) on Aug 30, 2007 at 12:17 UTC
In both cases, the the signal takes control away from the backticks and hands it to the signal handler. In the first example, the signal handler just prints a message and returns control to the backticks. That's why you get the message at five seconds. Since control returns to where it came from, the backticks finish (ten seconds after they started), and everything goes along as if there had been no alarm. In the second example, the signal handler uses die rather than just return. This way, it avoids returning control to the backticks. As such, `$yawn` is never set (it retains the value it had before the attempted assignment), and control flows out after the eval which caught the exception the signal handler threw.	[reply] [d/l]
Re^8: How to timeout if a call to an external program takes too long by BrowserUk (Patriarch) on Aug 30, 2007 at 12:38 UTC
So, as examples of "How to timeout a call to an external program" go, the first one is completely useless as it does nothing except print a message via a 'longcall'. And the second one, whilst returning control to the calling program, leaves the spawned program running (or hung) with no possible mechanism to terminate it. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^9: How to timeout if a call to an external program takes too long by kyle (Abbot) on Aug 30, 2007 at 14:47 UTC
Well, yes. If you're worried about terminating the spawned program, don't use backticks. Most of the time, I don't use backticks anyway. I'd much rather do something like this: `my $cmd_pid = open my $cmd_fh, '-\|', $cmd or die "Can't run '$cmd': $!\n"; my $yawn = do { local $/; <$cmd_fh> }; close $cmd_fh;` [download] It does the same thing, and it complains about errors, and it gives me the PID of the child process, which I can use to cause the sort of interruption you're looking for: `my $start_time = time; sub exec_time { return time - $start_time } my $cmd = 'sleep 3600 ; echo "yawn"'; my $yawn; my $cmd_pid = open my $cmd_fh, '-\|', $cmd or die "Can't run '$cmd': $!\n"; eval { local $SIG{ALRM} = sub { kill 15, $cmd_pid; die "alarm\n" }; alarm 5; $yawn = do { local $/; <$cmd_fh> }; alarm 0; }; close $cmd_fh; printf "(%d) yawn? $yawn", exec_time(); __END__ (5) yawn?` [download] Note that in this case, if I don't kill the child, the program will still hang when it gets to close, because that will wait for the pipe to finish. You can put the `close` inside the eval, but then you have a filehandle dangling open. Note also that if the child spawns a child (as it does in this case because the child is `sh -c`), then that grandchild is not killed. I don't see that there's much to do about that in any case. Also, just for the record, this morning I'm testing on a different machine. `kyle@xxx:~$ perl -v \| head -5 This is perl, v5.8.8 built for i486-linux-gnu-thread-multi Copyright 1987-2006, Larry Wall kyle@xxx:~$ uname -a Linux xxx 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GN +U/Linux` [download]	[reply] [d/l] [select]