You may also want to take a look at runN, which runs a program over a set of parameters. Also, BrowserUk provided me with a nice queue based thread solution.

or Proc::Queue:

use Proc::Queue size => 5, # => 5 parallel processes max.
                qw(system_back);

use POSIX ":sys_wait_h";
use Errno qw(EINTR);

my %pid2date;

sub reap_children {
  my $wait = shift;
  my $pid = waitpid(-1, ($wait ? 0 : WNOHANG));
  if ($pid > 0) {
    print "process for date $pid2date{$pid} (pid $pid) exited with cod
+e ". ($? >> 8) . "\n";
    return 1;
  }
  return ($! == EINTR);
}

while ($currentdate <= $enddate) {
  reap_children(0);
  print "$command\n";
  my $pid = system_back($command);
  $pid2date{$pid} = $currentdate;
  $currentdate = nextdate($currentdate);
}

1 while reap_children(1);
[download]

This is untrue.

This is only true for Win32, where the fork() call doesn't even really exists (it's poorly faked using threads), on every other platform fork() costs almost the same, and provides many valuable additional benefits (like better memory protection, better management etc etc)

Not to mention, he's spawning only 5 (count'em - five) processes, what would be cummulative gain on that, even on win32?

I agree that there is no difference if you would create as many threads as forked processes.
The difference is that you need to call fork once for every planned task - whereas in a thread model you can share data and thus you would start threads only 5 times depending on the number of workers as the workers can get the data from a queue instead of a function parameter.