That can't be right? All 3 proceesses are processing all 5 collections.

Rubbish. Perhaps this slightly modified code will help you see what is happening more easily:

C:\>type test.pl
use Parallel::ForkManager;
my @collections = qw (col1 col2 col3 col4 col5);
my $max_tasks = 3;
$pm = new Parallel::ForkManager($max_tasks);
$|++;
my $start = time();

for my $collection (@collections) {
    my $pid = $pm->start and next;
    printf "Begin processing $collection at %d secs.....\n", time()-$s
+tart;
    sleep rand(5)+2;
    printf ".... $collection done at %d secs!\n", time()-$start;
    $pm->finish;
}

C:\>perl test.pl
Begin processing col1 at 0 secs.....
Begin processing col2 at 0 secs.....
Begin processing col3 at 0 secs.....
.... col3 done at 3 secs!
Begin processing col4 at 3 secs.....
.... col1 done at 4 secs!
Begin processing col5 at 4 secs.....
.... col2 done at 5 secs!
.... col4 done at 6 secs!
.... col5 done at 9 secs!

C:\>
[download]

cheers

tachyon

#perl.exe -w

# INIT ----
use strict;
use Parallel::ForkManager;
use MyTest; # Mind this one, it's the one that messes things up

# VARS ----
my $max_procs = 10;
my $wait = 5;
my @collections = qw( adw adw_wet_compleet ag-dou ag-gi ag-hc ag-hlo a
+g-its-sol ag-its-sol-hot agents alg_diversen alg_dossier_juris_en_res
+o alg_ellis alg_ellis_en alg_kb alg_kfb alg_kluwer_rest alg_pdf alg_r
+est alg_sdu am b_adw b_adw_wet_compleet b_ag-dou b_ag-gi b_ag-hc b_ag
+-hlo b_ag-its-sol b_ag-its-sol-hot b_agents b_alg_diversen b_alg_doss
+ier_juris_en_reso b_alg_ellis b_alg_ellis_en b_alg_kb b_alg_kfb b_alg
+_kluwer_rest b_alg_pdf b_alg_rest b_alg_sdu b_am b_bibliotheek b_bm b
+_bna-mix b_browsedocs b_curbel b_fmod b_help b_hvg b_hvg-kluwer b_mrp
+ b_pz b_refdocs b_tss b_tss-pdf bibliotheek bm bna-mix  browsedocs cu
+rbel fmod help hvg hvg-kluwer images mrp pz refdocs tss tss-pdf );



# MAIN ----
my $pm =  new Parallel::ForkManager($max_procs);

# Setup a callback for when a child finishes up so we can
# get it's exit code
$pm->run_on_finish(
    sub { my ($pid, $exit_code, $ident) = @_;
        print "** $ident finished (PID: $pid) and exit code: $exit_cod
+e\n";
    }
);

$pm->run_on_start(
    sub { my ($pid,$ident)=@_;
        print "** $ident started, pid: $pid\n";
    }
);

$pm->run_on_wait(
    sub {
        print "** waiting\n";
    }, 0.5
);

foreach my $child ( 0 .. $#collections ) {
    my $pid = $pm->start($collections[$child]) and next;
    
    # This code is the child process
    print "Child: $collections[$child]\n";
    sleep $wait;
    # End of child process
    
    $pm->finish($child); # pass an exit code to finish
}

print "Waiting for Children...\n";
$pm->wait_all_children;
print "Everybody is out of the pool!\n";
[download]

package MyTest;

#---------------------------------------------------------------------
+---
#                                  INIT
#---------------------------------------------------------------------
+---
use strict;
use Win32::OLE;
use Win32::OLE::Variant;

1;
[download]

fork() on win32 is an emulation. It is known not to play well with Win32::OLE which tickles the bugs. There issue is the children segfaulting on exit.

You may be able to get something working with threads, then again you may not. I suggest the easiest way would be to use Win32::Process to fire up your 10 processes. They will all have there own perl interpretter so there should be no issues porvided you have enough memory. All you have to do is create you initial pool and loop over them waiting for one to exit so you can spawn the next one.

cheers

tachyon

Thanks for your quick reply tachyon,
The problem however is not how to fire up processes, but how to fire up a process for each collection, and the collection information is stored in a MSSQL database, so there is no way I can drop the Win32::OLE-thing.
Ofcourse I can try to code around this, which means I have to find another way to access the database, possibly causing other problems. Apparantly there is a downside to eveything, and I have to cope with that. The bad thing is I was counting on this to work since we have a serious problem here and by the end of this day our product goes live! Now I solved things with Win32::Process, each of the processes starting in it's own shell.
When the parent dies however the childers keep on going. Also The children are out of control, so our M$ machine died this weekend because 100's of 'CMD.EXE''s were romping around.
That's okay for monks, but not for lost processes. ;-) If you or anyone else 'sees the light', be welcome to help this lost monk.
In the meantime I'll start humming.
Hmmmmmmmmmmmmmmmmmmmmmmmmmm............. }-|
Rgds, John