in reply to Need a reliable way to send SIGINT to a perl process on 5.8.8/windows XPpro

I'm not surprised that $console->GenerateCtrlEvent(); doesn't affect the child process. Any console handle you have in your parent process is unlikely to have much effect upon your child process. If you were creating the child yourself and setting all the right flags and permissions on the CreateProcess() you might be able to affect the child using a handle in the parent, but not otherwise.

Try kill 21, $pid;. If that gets through to the child process, I may have an explanation for you.

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."

Replies are listed 'Best First'.
Re^2: Need a reliable way to send SIGINT to a perl process on 5.8.8/windows XPpro
by ikegami (Patriarch) on Mar 09, 2007 at 03:18 UTC

    I'm not surprised that $console->GenerateCtrlEvent(); doesn't affect the child process.

    According to the documentation for the underlying function (GenerateConsoleCtrlEvent), the signal is generated in all processes that share the console of the calling process when the process group id parameter is 0 like it is here. (If the parameter is not zero, all the processes in the specified process group are affected.) The child should be affected, meaning its event handler should be called if one was set.

    By the way, this function can be called as a static method: Win32::Console->GenerateCtrlEvent();. It's not really a console method at all.

[reply]
[d/l]
[reply]
        The way I read the OP, the problem is not sending the Ctrl-C or its effect on the child, the problem is to avoid killing the parent along with the child. According to the OP, setting $SIG{INT} to "IGNORE" used to accomplish that task in 5.6.1, but it doesn't anymore. That's what I addressed in my top level post. Do you see it differently? The OP wasn't all that clear.
[reply]
[d/l]
[select]
      The behavior we see on 5.6.1 matches the documentation, but on 5.8.8 it does not appear that the CTRL-C get through to the child process where we have the $SIG{INT} handler defined. I have tried using defaults which works on 5.6.1, and specifying CTRL_C_EVENT along with the pid directly and that doesn't seem to help either.
[reply]
Re^2: Need a reliable way to send SIGINT to a perl process on 5.8.8/windows XPpro
by fwashbur (Sexton) on Mar 09, 2007 at 21:37 UTC
    Interesting, so using the Break instead, my current acceptance test case seems to interrupt correctly in many cases although I get wild exit codes some times.
    However, trying just a simple test, this still does not work. For instance I have 2 scripts running in parallel, using one to attempt to send the signal to the other:
    WaitForCtrlC.pl: 
    use strict;
use warnings;

$SIG{INT} = sub {print "got ctrl-C in waitforctrlc\n"; exit 1;};
print "\nmy pid is $$\n";

while (1) {
   print "waiting for ctrl-C\n";
   sleep 2
}
# should never get here
print "made it past ctrl-C\n";
exit 0;

    [download]

    And then send the signal to the pid with SendCtrlC.pl: 
    use strict;
use warnings;

while (1) {
   print "Enter pid to signal:";
   my $pid = <STDIN>;
   chomp $pid;
   print "\nSending signal to $pid:...";
   kill 21, $pid;
   print "\n";
}

    [download]
[reply]
[d/l]
[select]
Re^2: Need a reliable way to send SIGINT to a perl process on 5.8.8/windows XPpro
by fwashbur (Sexton) on Mar 09, 2007 at 22:59 UTC
    Kudos to you! 
    kill 21, $pid;

    [download]
    works!, I just assigned $SIG{BREAK} to the same handler as $SIG{INT}. I know that manual CTRL-C gets me into the interrupt handler for $SIG{INT}. So now I can just use BREAK to test the handler.
    Thank you!!
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom