convenience", and to do anything you wanted in your signal handler,
and be prepared to clean up core dumps now and again.
-In Perl 5.7.3 and later to avoid these problems signals are
-"deferred"-- that is when the signal is delivered to the process by
+Perl 5.7.3 and later avoid these problems by "deferring" signals.
+That is, when the signal is delivered to the process by
the system (to the C code that implements Perl) a flag is set, and the
handler returns immediately. Then at strategic "safe" points in the
Perl interpreter (e.g. when it is about to execute a new opcode) the
never exit. A single process closing a pipe is not enough to close it;
the last process with the pipe open must close it for it to read EOF.
-There are some features built-in to unix to help prevent this most of
+Certain built-in Unix features help prevent this most of
the time. For instance, filehandles have a 'close on exec' flag (set
I<en masse> with Perl using the C<$^F> L<perlvar>), so that any
filehandles which you didn't explicitly route to the STDIN, STDOUT or
use IPC::SysV qw(IPC_PRIVATE IPC_RMID S_IRUSR S_IWUSR);
$size = 2000;
- $id = shmget(IPC_PRIVATE, $size, S_IRUSR|S_IWUSR) || die "$!";
+ $id = shmget(IPC_PRIVATE, $size, S_IRUSR|S_IWUSR) // die "$!";
print "shm key $id\n";
$message = "Message #1";
use IPC::SysV qw(IPC_CREAT);
$IPC_KEY = 1234;
- $id = semget($IPC_KEY, 10, 0666 | IPC_CREAT ) || die "$!";
+ $id = semget($IPC_KEY, 10, 0666 | IPC_CREAT ) // die "$!";
print "shm key $id\n";
Put this code in a separate file to be run in more than one process.