Re: Stacking Signal Handlers

A signal is a super abbreviated message - its literally a "one bit message" on/off. A common use for this particular signal is to force a daemon to re-read its config file. The entry for $SIG{'HUP'} starts off as undefined. The signal handler when installed, is essentially the address of a subroutine that receives exactly ZERO parameters. Of course that sub could call a number of subs which also take no parameters.

What that subroutine does is your business. Installing a signal handler is something that the main process code should do. Not something that happens because of the "use" statement of some module. The processing of this signal is a public interface that has application level not just module significance.

Comment on Re: Stacking Signal Handlers

Replies are listed 'Best First'.
Re^2: Stacking Signal Handlers by saintmike (Vicar) on Aug 30, 2010 at 05:34 UTC
Installing a signal handler is something that the main process code should do. Not something that happens because of the "use" statement of some module. As long as you're programming simple scripts in a bubble, that assumption might work. If, on the other hand, you're developing a framework to be used by others, you'll realize that this is a real-world problem that needs to be addressed -- ideally by a cookbook solution.	[reply]

Replies are listed 'Best First'.

Re^2: Stacking Signal Handlers
by saintmike (Vicar) on Aug 30, 2010 at 05:34 UTC

Installing a signal handler is something that the main process code should do. Not something that happens because of the "use" statement of some module.

If, on the other hand, you're developing a framework to be used by others, you'll realize that this is a real-world problem that needs to be addressed -- ideally by a cookbook solution.

[reply]