I have written the following piece of code to test signaling between child and parent. Ideally, when the child gives a SIGINT to parent the parent should come back in the new iteration and wait for user input. This I have observed in perl 5.8, but in perl 5.6.1(which I am asked to use) the parent is actually "killed". There is no next iteration.
my $parent_pid = $$;
$pid = fork();
if($pid == 0)
{
print "child started\n";
kill 2, $parent_pid;
}
else
{
while(1)
{
eval
{
$SIG{INT} = sub{die "GOTCHA";};
print 'inside parent'."\n";
$a = <>;
};
if($@)
{
print "got the signal!!!!\n$@\n";
next;
}
}
}
Could someone please give a walkaround for this problem or some other way to signal the parent so that it enters the new iteration.
The failure on 5.6.X might be because of the way Perl used to handle signals, which was fixed with 'Safe Signal Handling' in Perl 5.8.0. In either case, you are using a Perl which is practically archaeological and you should argue strongly to your masters that you should be using at least Perl 5.12, and ideally 5.14.
This is likely to be a race condition, caused by the child sending the SIGINT
before the parent was ready for it. Remember that after you fork()
you will have two independent processes, each might proceed at whatever pace it likes.
It's best in your case to set up the SIGINT
handler before the fork()
call, so you know it's definitely in place before the child tries to kill()
its parent.
(with some minor corrections):
$SIG{INT} = sub { die "GOTCHA" };
my $parent_pid = $$;
defined( my $pid = fork() ) or die "Cannot fork() - $!";
if($pid == 0)
{
print "child started\n";
kill INT => $parent_pid;
}
else
{
while(1)
{
eval
{
print "inside parent\n";
<>;
};
if($@)
{
print "got the signal!!!!\n$@\n";
next;
}
}
}