Trying to combine timeout with getting program's pid

[dn_perl]

I am trying to timeout an external program, and if it is timed
out, I want to kill it.

I have used the following code :

#!/usr/local/bin/perl

use strict ;

my $timeout = 6 ;
my $my_pid ;

eval {
local $SIG{ALRM} = sub { die "alarm\n" }; # NB: \n required
alarm $timeout;
system("/mydir/my_program") ; # stmt 1
# $my_pid = open EXTRACT , " /mydir/my_program | " ; # stmt 2
alarm 0;
};
if ($@) {
die unless $@ eq "alarm\n"; # propagate unexpected errors
print "killing process\n" ;
# timed out
}
else {
# didn't time out
}
print "my_pid is $my_pid Z\n" ;
-----------

my_program runs for 20 seconds. So it is always timed out. But
I want to kill it before that.
The problem is : if I use "system" command to start the external
program, I pass if($@) condition and can do some processing.
However I do not know PID of my_program in that case.
But if I comment out "system" cal and use stmt 2 instead to
start the process and get its PID, I can't pass if($@) condition.

(And when I run the command : open EXTRACT , " /mydir/my_program | "
what is the program's output geting piped *to* ??)

Please advise how I should get around this problem.
Thanks in advance.

 

[Larry]

See the current topic "How to kill a forked process".

Basically, you are going to have to do your own "fork", "exec", and
"wait" instead of using "system" which does those calls for you.

(Incidentally, this looks like a great problem for a CPAN module to
solve... it's probably been done already, but I don't know. Anyone?)

That method also has the advantage of not using the "alarm" call, which
has problems on all but the newest Perl versions.

As for your second question... "what is the program's output getting
piped to?". It's being piped to the EXTRACT filehandle. When you read
from that handle, you'll get the program's output.

 

[A. Sinan Unur]

See the current topic "How to kill a forked process".

Who should see that topic and why?

Please quote an appropriate amount of context when replying.

Sinan

 

[dn_perl]

As for your second question... "what is the program's output getting
piped to?". It's being piped to the EXTRACT filehandle. When you read
from that handle, you'll get the program's output.

By the way, what is the philosophy/logic behind FILEHANDLE not
requiring to be declared and used as a scalar?

 

[Anno Siegel]

By the way, what is the philosophy/logic behind FILEHANDLE not
requiring to be declared and used as a scalar?

It isn't used as a scalar, it is used as a filehandle. Filehandles
don't have a sigil (like $ for scalars, @ for arrays, etc.), so they
can be given as barewords. Look for filehandle in perldata for more.

Anno

 

[Paul Lalli]

By the way, what is the philosophy/logic behind FILEHANDLE not
requiring to be declared and used as a scalar?

A filehandle is not a scalar, any more than it is an array or a hash.
It is a separate type of Perl variable.

You can, however, store a reference to a filehandle in a scalar
variable. Indeed, that is generally the preferred method of using
filehandles. Perl will even automatically create the filehandle,
create a reference to it, and store it in a given scalar, all for you:

open my $fh, '<', 'file.txt' or die "Cannot open file.txt: $!";
while (<$fh>){
print;
}

As long as $fh is undefined before you use it in the open() command
(and since you're declaring it there, it has to be undefined...), you
can use the reference that Perl put in $fh exactly as you would use a
filehandle itself.

This has at least two benefits that immediately come to mind:
1) $fh is a scalar variable that is subject to `use strict;`, so if you
accidentally do
my $line = <$fj>;
Perl will tell you that's wrong.

2) $fh is a lexical variable, and once it goes out of scope, the
filehandle it references will automatically be closed for you.

Paul Lalli

 

[xhoster]

By the way, what is the philosophy/logic behind FILEHANDLE not
requiring to be declared and used as a scalar?

I think that that was more of a mistake than a philosophy.

Xho