X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=pod%2Fperlipc.pod;h=5f8af22550b298aa93b45578a52acf9a6976e7f2;hb=e77edca30a2be27033e243f6b69dee5191c27b5a;hp=96cfa8ce707994b82ede1fa737eb2d1e3f3f5991;hpb=45c0772f5bfdb04cae12ed9cd75ccf427acaa981;p=p5sagit%2Fp5-mst-13.2.git

diff --git a/pod/perlipc.pod b/pod/perlipc.pod
index 96cfa8c..5f8af22 100644
--- a/pod/perlipc.pod
+++ b/pod/perlipc.pod
@@ -35,7 +35,7 @@ and then raise an exception.  That's because on most systems,
 libraries are not re-entrant; particularly, memory allocation and I/O
 routines are not.  That meant that doing nearly I<anything> in your
 handler could in theory trigger a memory fault and subsequent core
-dump - see L<Deferred Signals> below.
+dump - see L</Deferred Signals (Safe Signals)> below.
 
 The names of the signals are the ones listed out by C<kill -l> on your
 system, or you can retrieve them from the Config module.  Set up an
@@ -95,13 +95,22 @@ it doesn't kill itself):
     }
 
 Another interesting signal to send is signal number zero.  This doesn't
-actually affect another process, but instead checks whether it's alive
+actually affect a child process, but instead checks whether it's alive
 or has changed its UID.
 
     unless (kill 0 => $kid_pid) {
 	warn "something wicked happened to $kid_pid";
     }
 
+When directed at a process whose UID is not identical to that
+of the sending process, signal number zero may fail because
+you lack permission to send the signal, even though the process is alive.
+You may be able to determine the cause of failure using C<%!>.
+
+    unless (kill 0 => $pid or $!{EPERM}) {
+	warn "$pid looks dead";
+    }
+
 You might also want to employ anonymous functions for simple signal
 handlers:
 
@@ -279,7 +288,7 @@ to find out whether anyone (or anything) has accidentally removed our fifo.
 	sleep 2;    # to avoid dup signals
     }
 
-=head2 Deferred Signals (Safe signals)
+=head2 Deferred Signals (Safe Signals)
 
 In Perls before Perl 5.7.3 by installing Perl code to deal with
 signals, you were exposing yourself to danger from two things.  First,
@@ -340,6 +349,32 @@ the signal flags and calls %SIG handlers before resuming IO operation.)
 Note that the default in Perl 5.7.3 and later is to automatically use
 the C<:perlio> layer.
 
+Note that some networking library functions like gethostbyname() are
+known to have their own implementations of timeouts which may conflict
+with your timeouts.  If you are having problems with such functions,
+you can try using the POSIX sigaction() function, which bypasses the
+Perl safe signals (note that this means subjecting yourself to
+possible memory corruption, as described above).  Instead of setting
+C<$SIG{ALRM}> try something like the following:
+
+    use POSIX;
+    sigaction SIGALRM, new POSIX::SigAction sub { die "alarm\n" }
+        or die "Error setting SIGALRM handler: $!\n";
+
+=item Restartable system calls
+
+On systems that supported it, older versions of Perl used the
+SA_RESTART flag when installing %SIG handlers.  This meant that
+restartable system calls would continue rather than returning when
+a signal arrived.  In order to deliver deferred signals promptly,
+Perl 5.7.3 and later do I<not> use SA_RESTART.  Consequently, 
+restartable system calls can fail (with $! set to C<EINTR>) in places
+where they previously would have succeeded.
+
+Note that the default C<:perlio> layer will retry C<read>, C<write>
+and C<close> as described above and that interrupted C<wait> and 
+C<waitpid> calls will always be retried.
+
 =item Signals as "faults"
 
 Certain signals e.g. SEGV, ILL, BUS are generated as a result of