Re^3: Backticks and SIGALRM

Ah, OK. So you want to be able to kill off the offending sub-process when the alarm fires? Then you either need to walk the process table, looking for a process whose parent is your script, or start the process in a way which allows you to get the pid and the output.

e.g. run the code under a piped open, something like this (untested):

   my $cmd = "your command";
   my $pid = open(my $fh, "$cmd|");
   $SIG{ALRM} = sub {
     print "Alarm fired, killing pid $pid\n";
     # Replace with windows-specific code to kill process
     kill 15, $pid;
   };
   die "Can't run command [$cmd] : $!" unless $pid;

   # Or do some other processing with $fh
   push @result, $_ while (<$fh>);
   close $fh
     or die "Problem running [$cmd] : $?";
[download]

If your child process starts yet more children (and they don't exit when the parent is killed), you'll have to write more elaborate cleanup code.

Dig through the windows-related process modules on CPAN and you should find what you need for the cleanup.

Comment on Re^3: Backticks and SIGALRM Download Code

Replies are listed 'Best First'.
Re^4: Backticks and SIGALRM by sgt (Deacon) on Aug 21, 2007 at 14:14 UTC
Just a minor pick (which applies to all posted solutions so far) , on unixlike the killing part should be in at least two stages: first send signal of normal termination (SIGTERM) and then signal of immediate termination (SIGKILL) to let the ext. app a chance to clean up. In some cases even stop/cont signals can be appropriate. It is probably better to send signal to the process group id (perl kill with negative signal, or system shell kill with negative pid) or to take care of the external app potential children (or simply imagine you fired a shell...); if the external app has acted "daemonic" then one should have knowledge about the app's behaviour, /proc or a process table walker could be of help. cheers, --stephan	[reply]

Replies are listed 'Best First'.

Re^4: Backticks and SIGALRM
by sgt (Deacon) on Aug 21, 2007 at 14:14 UTC

Just a minor pick (which applies to all posted solutions so far) , on unixlike the killing part should be in at least two stages: first send signal of normal termination (SIGTERM) and then signal of immediate termination (SIGKILL) to let the ext. app a chance to clean up. In some cases even stop/cont signals can be appropriate. It is probably better to send signal to the process group id (perl kill with negative signal, or system shell kill with negative pid) or to take care of the external app potential children (or simply imagine you fired a shell...); if the external app has acted "daemonic" then one should have knowledge about the app's behaviour, /proc or a process table walker could be of help.

[reply]