#!/bin/sh
script1 &
script2 &
.
.
script30 &
[download]

If that's all you basically need, then writing a complicated Perl program with forking, signal-handling and all that seems a bit of an overkill. :)

But, don't you see, that using the *shell*. That's blasphemy. No amount of arduous work could ever convince a monk to use a (*gasp*) shell script! Never! ;)

redmist
redmist.dyndns.org
redmist@altavista.net

system(1,"command");
[download]

This is the undocumented (as far as I could find) way to start commands in the background portably for recent versions of Perl. I'm surprised that it is still undocumented.

I found it hard to understand tilly's script because I am pretty new to Perl (I really did try, though). The way I ended up solving this problem was:

# Created on 9/6/00 by Jonathan E. Dyer

@servers=('server1','server2','server3','server4','server5','server6',
+'server7','server8','server9');


use Win32::Process;
sub ErrorReport{
    print Win32::FormatMessage( Win32::GetLastError() );
        }

foreach $server (@servers){
    Win32::Process::Create($ProcessObj,
                "c:\\perl\\bin\\perl.exe",
                "perl.exe c:\\findstuff6.pl -s$server",
                0,
                NORMAL_PRIORITY_CLASS,
                ".")|| die ErrorReport();

    #$ProcessObj->Suspend();
    #$ProcessObj->Resume();
    #$ProcessObj->Wait(INFINITE);
}
[download]

The problem that caused me the biggest headache was the third variable in win32::process. I kept forgetting to put perl.exe before the script, assuming that this was covered by variable 2.

I hope this helps if anyone runs into the same issue...

-OzzyOsbourne

Personally I hate using platform specific modules if I can avoid it. When you start with a nice portable language, it is worth a little effort to not lose portability.

The key to my approach is the IPC::Open3 module and the wait command. The module exports open3, which lets you launch a process with specified STDIN, STDOUT, and STDERR. The return of that is a process ID. Conversely wait will collect the return of a process you launched (the processes are called "children" and this is called "reaping the process" since it is the last step before the process can finish dying) returning the process ID and setting $? to its return code.

What I did is launched processes hooked directly to my output but supressing all input (because there is no easy way to sort out you being able to talk to 5 processes at once on one pipe) and kept track of what I launched. When I reaped them if there was a problem I would give a message based on what I had. My logic was complicated by the fact that I might have 200 jobs to launch, but don't want to run more than 5 at a time. However that is the idea.

See if you can't get that to work. If you do you will both have more portable code and will have learned a lot about process communication..both good things IMO. :-)

my $kids = 0;

for ( 1..30 ) {
    if ( fork ) {
        waitpid(-1,0) && $kids++;
    } else {
        exec('scriptname') or die "Bad Things: $!;
    }
}

while ( $kids < 30 ) {
    waitpid(-1,0) && $kids++;
    sleep(1);
}
[download]

When you do that, you need to make sure you're reaping your task kids. Remember that pipe-opens and fork-opens also generate kids that may not be part of your "30 count".

A better way is to fork your kids, noting their pid as keys in a hash. When you reap a kid, delete it from the hash. If it wasn't part of the hash, it won't affect the count. Then fork new kids (on the block? {grin}) until your hash has 30 keys again.

I've done this for at least one of my columns, but after 106 by-lines, I can't remember which one anymore. {grin}

-- Randal L. Schwartz, Perl hacker

At a guess, one you can't post on your website yet because it is too recent. Anyways, I used a somewhat similar approach in Run commands in parallel in case what merlyn said is opaque to you.

That way you won't have to wait to find out how to reap a kid. :-)