in reply to Catching signals

You're not doing anything to synchronize your parent and child processes, so there's no guarantees which one will execute the if first.

It's possible you send that signal to the child before the local $SIG{INT} is executed, for instance.

Try setting $SIG{INT} before the fork, and see what happens. Don't forget to add $$ to what the die prints out, though.

I'd test it myself, but signal handling in perl on cygwin has a horrible tendency to hang my whole NT system...
--
Mike

Replies are listed 'Best First'.
Re: Re: Catching signals
by Anonymous Monk on Sep 04, 2002 at 17:38 UTC
    putting the $SIG{INT} in front of the fork() did not do anything. I even put in a for (1 .. 1000000){} loop just in front of the kill command, to give the child some time to process, but even at that, no signal is detected.
[reply]
      Try putting the signal handler before the fork() and adding a sleep(1) to the child (between the two prints) so it doesn't finish before it receives the signal.
[reply]

      A big ol' for loop is no substitute for a nice little sleep statement.

      -sauoq
"My two cents aren't worth a dime.";
[reply]
        well, as far as forking is concerned, if i remember by Unix systems course, each process gets a slice of the processor, so even though one is stuck in the for (;;) loop, the other process should still execute. So in that sense, here, a sleep = for ();
[reply]
      Hmmm, what platform/perl version are you trying this on?

      I'm guessing your perl or your os may not like signals...
      --
      Mike

[reply]
        its ActivePerl 5.6.1 build 633 (multi-thread) running under Windows NT (perl is actually called from within the cygwin environment, however, execution of program from outside of cygwin still has the same effect)
[reply]

In Section Seekers of Perl Wisdom