Re^4: SIG{INT} not handling CTRL-C ???

in reply to Re^3: SIG{INT} not handling CTRL-C ???
in thread SIG{INT} not handling CTRL-C ???

In my implementation ,the parent as well as it's children will be running in an infinite loop.

In this scenario, would defining the CTRL-C handler to kill the children when I hit the CTRL-C key be a feasible option?

Comment on Re^4: SIG{INT} not handling CTRL-C ???

Replies are listed 'Best First'.
Re^5: SIG{INT} not handling CTRL-C ??? by afoken (Chancellor) on Jul 14, 2010 at 23:54 UTC
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 -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l]

Replies are listed 'Best First'.

Re^5: SIG{INT} not handling CTRL-C ???
by afoken (Chancellor) on Jul 14, 2010 at 23:54 UTC

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

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

[reply]
[d/l]

In Section Seekers of Perl Wisdom