Perl dropping signals?

DrWhy has asked for the wisdom of the Perl Monks concerning the following question:

We're working on a home-grown search engine daemon here and are having some trouble with signal handling (under 5.6.1, and 5.8.x). We have two processes: the actual search daemon and a watcher. The watcher will automatically restart the search engine under various circumstances, e.g. when the search database has had sufficiently significant changes made to it, or when the search engine dies/is killed.

The problem is that in our testing it appears that some of the signals are not getting through to our handlers. It looks like something -- the perl engine maybe? -- is trapping and ignoring some signals before our handlers have a chance at them. The problem appears to be timing-related. When two signals are generated close together in time (on the order of milliseconds) the first signal never makes it to our code, but the second one does.

Does this scenario ring a bell with anyone out there?

Comment on Perl dropping signals?

Replies are listed 'Best First'.
•Re: Perl dropping signals? by merlyn (Sage) on Aug 10, 2004 at 22:37 UTC
It's probably not Perl. It could very well be the kernel. A signal is only a request that at some point in the future, an interrupt might be taken if the process is interested. The queue is only 1-bit deep... if two signals come in before the interrupt is taken on the first one, the second one is viewed as "redundant" and deleted. Thus, never design a protocol where the number of signals matters. Only that a signal has been triggered since the last time you noticed. -- Randal L. Schwartz, Perl hacker Be sure to read my standard disclaimer if this is a reply.	[reply]
Re^2: Perl dropping signals? by DrWhy (Chaplain) on Aug 10, 2004 at 23:02 UTC
Thanks, Randal! I have a brief (I hope) followup question. Actually, two questions. Is this behavior the same to your knowledge on all *nixes -- we're using Solaris and Debian Linux. Does it matter whether the two signals are different signals or the same, i.e., two SIGCHLD's vs a SIGCHLD and SIGUSR2?	[reply]
Re: Perl dropping signals? by ysth (Canon) on Aug 11, 2004 at 00:11 UTC
5.6.1 and 5.8.x have very different signal handling. In 5.6.1 signals are handled immediately, and if the interrupted perl code is in a critical place, a coredump can result. In 5.8.x, by default, signal handling is deferred until a safer time. Perhaps this could explain what you are seeing. See http://search.cpan.org/~nwclark/perl-5.8.5/pod/perl58delta.pod#Safe_Signals and http://search.cpan.org/~nwclark/perl-5.8.5/pod/perlipc.pod#Deferred_Signals_(Safe_Signals).	[reply]
Re^2: Perl dropping signals? by Joost (Canon) on Aug 11, 2004 at 09:14 UTC
If safe signals are the problem, they can be disabled by setting the PERL_SIGNALS environment variable. From perlrun: PERL_SIGNALS In Perls 5.8.1 and later. If set to "unsafe" the pre-Perl-5.8.0 signals behaviour (immediate but unsafe) is restored. If set to "safe" the safe (or deferred) signals are used. See "Deferred Signals (Safe signals)" in perlipc. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]

PERL_SIGNALS