Unless I'm missing a subtlety, I don't think what I'm proposing involves more than a parent process waiting directly upon several child processes.

The "process to wait for a process" arises when you use modules like Parallel::ForkManager as a substitute for threading, as someone else suggested.

That is, you cannot ask P::FM to start the processes you want directly. Instead, it forks your current program and you then start the process you want to start from that subprocess, whilst the main process continues. It's a messy solution at best.

The piped-open is asynchronous, thus you can use it to start multiple concurrent processes directly from your main process without problem.

However, most times you don't only want to start the subprocess, but also monitor (is it still running?) and control (eg. kill it if it takes to long) and at least, eventually receive information that it has ended successfully or otherwise.

For all of these things, having the pid of the actual subprocess started is necessary; and the piped-open gives you that control. It also gives you access to that subprocesses output; which is easily and economically discarded if not required.

That worked nicely. Code snippet:

my $mysql = q{/usr/local/mysql/bin/mysql --host= [...]};
my @fh;
my $i = 0;
for my $sql (
             q{SELECT id INTO OUTFILE \'/sort/clh/na\' FROM addr},
             q{SELECT id INTO OUTFILE \'/sort/clh/ne\' FROM email},
             q{SELECT id INTO OUTFILE \'/sort/clh/np\' FROM phone}
            ) {
    my $cmd = "echo $sql | $mysql";
    open( $fh[$i++], '-|', $cmd )
      or die "Failed opening $sql: $!\n";
}
say "All spawned - waiting";
for my $i (0..$#fh) {
    while (defined (my $line = readline( $fh[ $i ] ))) {
        print "FH$i: $line";
    }
}
[download]

And as you pointed out, I could use IO::Select if I cared about knowing when each command finished.