if (my $pid = fork) {
# Parent
local $SIG{INT} = 'IGNORE';
local $SIG{QUIT} = 'IGNORE';
waitpid($pid, 0);
} elsif (defined $pid) {
# Child
exec 'date';
die 'date not found'
} else {
die "Can't fork: $!";
}
Which is the same thing, but in my opinion a little easier to read.
Why do you ignore those signals? I know near to nothing about signals and would like to learn (have only used HUP to reload configuration files, and Perl's __DIE__/__WARN__).
Juerd
- http://juerd.nl/
- spamcollector_perlmonks@juerd.nl (do not use).
| [reply]
[d/l] |
| [reply] |
I've written this both ways before, but generally prefer the style that
merlyn used in the snippet. I like to see potential failures at
the beginning of a block of code if it makes sense (it does to me in this snippet). It also fits my brain best to see the
child before the parent, since it will most likely be doing the heavy lifting.
After all this talk of child labor is reminding me of William Blake's "The Chimney Sweeper". Guess I have my night reading lined out for me ;-)
-- dug
| [reply] |
I've often found for what I'm using system() for that the implicit fork inherent in a open(CHILD, "|-") is a useful way to go. I get the fork plus control over the child's STDIN in one shot. I also get an automatic waitpid call when I close the parent side.
For example, culled from production code in a case where we don't want the child process to have any possible way to be still talking to the controlling terminal:
# my $status = system($command);
# Our better version of system()
my $status;
my $pid = open(KID_STDIN, "|-");
if (not defined $pid) {
die "cannot fork: $!; bailing out";
}
if ($pid) { ## parent
close(KID_STDIN);
$status = $?;
} else {
POSIX::setsid(); # disconnect from controlling terminal
open(STDOUT, ">> $_LogFileName");
open(STDERR, '>&STDOUT');
exec($command);
}
In the specific example here, we're using system to run java programs which read from data files given as parameters and produce log output on STDOUT, with exceptional output (such as an uncaught runtime exception that produces a stacktrace) going to STDERR. Because java plays games with its signal handlers, we discovered that running the driver perl script under "nohup" did not in fact allow us to start the driver script up and let it run in the background - java would still abort when the initial xterm was closed. Rewriting system() to include the setsid call finally fixed that problem. | [reply]
[d/l] |
