If you set up a SIGINT handler like mine, it will propagate the SIGINT to all children you track in %pids. That's all.

If you want SIGINT to also abort your main program, you must somehow abort the infinite loop in it. My examples stop as soon as all children have exited. That may or may not be sufficient. Perhaps you also need to set a "stop" flag inside the SIGINT handler, and modify the infinite loop to break as soon as the "stop" flag is set.

What your forked child processes do when they receive a SIGINT depends on what signal handler they have installed. They may simply ignore the signal. They may have the default handler installed that terminates the process. They may have a custom handler installed that does a completely different thing.

There is a convention for sending signals to abort a process gracefully, in order of decreasing politeness: First, you send SIGINT (i.e. tell the process "the user wants you to stop what you are doing") once or twice, and wait a little while. If that does not terminate the process, try SIGHUP (connection hang up) if the process runs on a terminal. (Daemons often abuse SIGHUP to re-read their configuration.) Next, try SIGTERM ("terminate now"). If even that does not work, and you don't care about data loss, nuke the process out of the process list by sending it the SIGKILL signal. That signal can not be caught, it WILL terminate the process without giving it a chance to save data.

Have a look at perlipc, especially the signals section, and at http://en.wikipedia.org/wiki/Signal_%28computing%29.

Update: Also note that Windows has no concept of signals, just a few signals are emulated by the Perl ports for Windows, and the emulation is not perfect. I.e. don't use signals on Windows.

Alexander