=head1 TITLE

Safe signal-handling for Perl.

=head1 VERSION

  Maintainer: Nathan Torkington <gnat@frii.com>
  Date: 30 Jul 2000
  Version: 2
  Mailing List: perl6-internals
  Number: 1

=head1 ABSTRACT

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.

=head1 DESCRIPTION

Signals may leave Perl in an inconsistent state, so that an inocuous
C<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.

=head1 IMPLEMENTATION

There are two choices for implementation: checkpointing, and event
loop. [Editor's note: the other RFC I refer to is fictitious]

=head2 Checkpointing

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.

=head2 Event loop

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.

=head1 REFERENCES

  RFC 6: "Standard Event Loop"
  perlvar manpage for discussion of %SIG