Re^3: Perl Signals

Starting with 4.3BSD and System V Release 3, signal handlers remain installed after a signal occurs. So, yes, the requirement to re-install a signal handler is some super ancient (many decades ago) stuff. No modern system and no POSIX compliant system will cause an installed signal handler to be affected. I would think that the Perl docs should be updated.

Now, this while() loop in the reaper is definitely needed! Signals are not "queued" for delivery. When a signal occurs, always interpret that to mean "at least one and maybe more than one of this signal has occurred".

Update: Wiki ATT releases SVR3, SVR4. SVR3 was GA'ed in 1986. I figure after 25 years, we don't have to worry much about R2 any more!

Comment on Re^3: Perl Signals

Replies are listed 'Best First'.
Re^4: Perl Signals by afoken (Chancellor) on Nov 17, 2011 at 16:51 UTC
[...] the requirement to re-install a signal handler is some super ancient (many decades ago) stuff. [...] I would think that the Perl docs should be updated. So do I. this while() loop in the reaper is definitely needed I have no problem with the while loop in the reaper, it is properly explained in perlipc. On the other hand, so is the problem with old SysV behaviour: But that will be problematic for the more complicated handlers that need to reinstall themselves. Because Perl's signal mechanism is currently based on the signal(3) function from the C library, you may sometimes be so unfortunate as to run on systems where that function is "broken"; that is, it behaves in the old unreliable SysV way rather than the newer, more reasonable BSD and POSIX fashion. So you'll see defensive people writing signal handlers like this: I think the paragraph cited above and the two examples following it should be moved into a new section "Signal Handlers on Ancient Systems" ("pre-POSIX systems"?), and be replaced with text and examples that concentrate on handling SIGCHLD / wait / waitpid instead of working around ancient API problems. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply]

Replies are listed 'Best First'.

Re^4: Perl Signals
by afoken (Chancellor) on Nov 17, 2011 at 16:51 UTC

[...] the requirement to re-install a signal handler is some super ancient (many decades ago) stuff. [...] I would think that the Perl docs should be updated.

So do I.

this while() loop in the reaper is definitely needed

I have no problem with the while loop in the reaper, it is properly explained in perlipc.

On the other hand, so is the problem with old SysV behaviour:

But that will be problematic for the more complicated handlers that need to reinstall themselves. Because Perl's signal mechanism is currently based on the signal(3) function from the C library, you may sometimes be so unfortunate as to run on systems where that function is "broken"; that is, it behaves in the old unreliable SysV way rather than the newer, more reasonable BSD and POSIX fashion. So you'll see defensive people writing signal handlers like this:

I think the paragraph cited above and the two examples following it should be moved into a new section "Signal Handlers on Ancient Systems" ("pre-POSIX systems"?), and be replaced with text and examples that concentrate on handling SIGCHLD / wait / waitpid instead of working around ancient API problems.

Alexander

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

[reply]