#!/usr/bin/perl -wT
use strict;

%ENV = ();           # clean out the %ENV hash to prevent mischief
$ENV{PATH} = '/bin';

my @pids;                                   # array for storing childr
+ens pids
my $cmd = 'sleep 2; echo "I am child $$"';  # command children will ex
+ecute

for (1..4) {
  my $childpid = fork() or exec($cmd);  # fork off a child
  push(@pids,$childpid);                # store the childs pid in @pid
+s
}

print "My Children: ", join(' ',@pids), "\n";

waitpid($_,0) for @pids;                # wait for children to finish
print "Children are done\n";
[download]

-Blake

You should really check the return values from fork() and exec() or you can get yourself into a lot of mess.

If fork() was not able to fork, it will return undef and if exec() is not able to run the program it will return.

my $pid = fork();
if ($pid) {
  push @pids, $pid;
}
elsif (defined $pid) {
  exec($cmd);
  die "Cannot exec '$cmd': $!\n";
}
else {
  die "Cannot fork: $!\n"
}
[download]

Not catching the exec is potentially the most dangerous as the child process then continues in the loop, just the same as the parent. In this cas you would end up filling the process table.

Good point. I certainly should have checked the return values. There is a large potential bug lying in wait there.

I don't think this would ever fill up the proc table though, The loop is bound by a for (1..4) which means that in the wost case, we would have:

1 parent  through the first time     (creates 1 child)
1 parent  1 child the second time    (creates 2 children)
2 parents 2 children the third time  (creates 4 children)
4 parents 4 children the fourth time (creates 8 children)
[download]

So at most I see a possible 16 procs being active at once.... of course they might never exit due to the messed up @pids array, but thats another matter.

Again, thanks for the catch.

-Blake

You already have a reply from blakem which provides a piece of code demonstrating the use of fork & exec. If you'd like more info, doing a Super Search for nodes containing 'fork' and 'exec' in the text comes up with a lot of useful looking hits.

Your best bet might be to roll the fork()/exec() yourself, so that the parent process can get the child pid directly from fork().

Hope this helps,
C-Keen

my $cmd = "process_file -c arg1 -d arg2";
for(1..40)
{
    if(!WINDOWS)
    {
        system("$cmd > /dev/null &");
    }
    else
    {
        system("sh -c \"$cmd > /tmp/null \"&");
    }
}
[download]

With this approach in mind, your best solution would be to iteration through the process table following execution of your system processes. Under *NIX, you would want to use Proc::ProcessTable (which I have written about before here). For Windows, you should take a look at either Win32::Process or Win32::ProcFarm.

Even so, I still think that you would find the best solution from pre-forking within your script, rather than launching system processes and detaching yourself from the controlling tty. This pre-forking approach would give you greater control, without the need to extraneous loops and control structures, of your spawned processes.

 

Ooohhh, Rob no beer function well without!