[ I posted this in reply to Robert's message, forgetting that before
I made nice posts with the section and question as the subject ]
I basically gutted this answer. If people want to know the gory
details about signals, they can read about it elsewhere (and the
answer already points to perlipc and the Camel.
Index: perlfaq8.pod
===================================================================
RCS file: /cvs/public/perlfaq/perlfaq8.pod,v
retrieving revision 1.20
diff -u -d -r1.20 perlfaq8.pod
--- perlfaq8.pod 7 Feb 2004 04:29:50 -0000 1.20
+++ perlfaq8.pod 4 May 2004 14:19:25 -0000
@@ -413,31 +413,30 @@
Signals are documented in L<perlipc/"Signals"> and the
section on ``Signals'' in the Camel.
-Be warned that very few C libraries are re-entrant. Therefore, if you
-attempt to print() in a handler that got invoked during another stdio
-operation your internal structures will likely be in an
-inconsistent state, and your program will dump core. You can
-sometimes avoid this by using syswrite() instead of print().
-
-Unless you're exceedingly careful, the only safe things to do inside a
-signal handler are (1) set a variable and (2) exit. In the first case,
-you should only set a variable in such a way that malloc() is not
-called (eg, by setting a variable that already has a value).
+You can set the values of the %SIG hash to be the functions you want
+to handle the signal. After perl catches the signal, it looks in %SIG
+for a key with the same name as the signal, then calls the subroutine
+value for that key.
-For example:
+ # as an anonymous subroutine
+
+ $SIG{INT} = sub { syswrite(STDERR, "ouch\n", 5 ) };
+
+ # or a reference to a function
+
+ $SIG{INT} = \&ouch;
+
+ # or the name of the function as a string
+
+ $SIG{INT} = "ouch";
- $Interrupted = 0; # to ensure it has a value
- $SIG{INT} = sub {
- $Interrupted++;
- syswrite(STDERR, "ouch\n", 5);
- }
+Perl versions before 5.8 had in its C source code signal handlers which
+would catch the signal and possibly run a Perl function that you had
set
+in %SIG. This violated the rules of signal handling at that level
+causing perl to dump core. Since version 5.8.0, perl looks at %SIG
+*after* the signal has been caught, rather than while it is being
caught.
+Previous versions of this answer were incorrect.
-However, because syscalls restart by default, you'll find that if
-you're in a "slow" call, such as <FH>, read(), connect(), or
-wait(), that the only way to terminate them is by "longjumping" out;
-that is, by raising an exception. See the time-out handler for a
-blocking flock() in L<perlipc/"Signals"> or the section on ``Signals''
-in the Camel book.
=head2 How do I modify the shadow password file on a Unix system?
--
brian d foy, [EMAIL PROTECTED]
