| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
Safe signal-handling for Perl.
Maintainer: Nathan Torkington <[email protected]> Date: 30 Jul 2000 Version: 2 Mailing List: perl6-internals Number: 1
The signal-handling mechanism in Perl 5 is not safe, but should be. The two main candidates for implementation are delayed delivery via checkpointing and the event loop.
Signals may leave Perl in an inconsistent state, so that an inocuous
print in a signal handler might trigger a core-dump. This is
referred to as "unsafe signals".
Signal safety is crucial. Signals are how timeouts, child process deaths, and many other important things are conveyed to a program. Many programs with operating-system interaction require signals, and core-dumps are unacceptable.
There are two choices for implementation: checkpointing, and event loop. [Editor's note: the other RFC I refer to is fictitious]
If the Perl interpreter checkpointed itself at internally consistent states, those states could be used to deliver signals. This would delay delivery, however, and the semantics of delayed signals might make some programs impossible to write correctly.
RFC 6 describes a desired event loop mechanism. If the existing signal mechanism (%SIG) were dropped, signals could simply become events that a program might or might not respond to. This would be a new model of signal handling which would make it difficult to reuse algorithms and code for systems programming from C.
RFC 6: "Standard Event Loop" perlvar manpage for discussion of %SIG