That's not a problem. start reaps children as well. Consider the following example:

my $max_children = 5;
my $pm = Parallel::ForkManager->new($max_children);
for my $i (0..9) {
    $pm->start and next;
    #...
    $pm->finish;
}
$pm->wait_all_children;
[download]

• The 6th start will reap a child.
• The 7th start will reap a child.
• The 8th start will reap a child.
• The 9th start will reap a child.
• The 10th start will reap a child.
• wait_all_children will reap the remaining 5 children.

With your infinite loop, it's no different. You'll be reaping child every time you create one (once you've created $max_children children).

It's a bug to use waitpid in a run_on_finish handler since the process has already been reaped by then.

Is that true? I thought that $pm->finish did the reap, and allowed the manager to start another process (assuming that $max_procs processes have been started already)?

So the OPs code would maintain $max_procs children at all time (because of the while (1) ), and as you said, no explicit cleanup or reaping need be added, because of the wonderfulness of Parallel::ForkManager!

Just a something something...

I thought that $pm->finish did the reap

finish is only executed in the child. It can't do any reaping.

$pm->finish;
[download]

run_on_finish is called in the parent process immediately after reaping the child (to get its exit code). It surprises me that it would be called "much later" since the parent is constantly checking if a child has ended if you use the formula in the documentation.

The only reason it wouldn't be responsive is if you have slow code that executes in the parent. This would delay start getting called, which would delay checking if children have ended. Note that start will actually reap multiple children if more than one have ended.

Allow me to post the complete code to explain what I see happening. The context is a worker application that watches a beanstalk message queue, forks a child to handle the request and immediately goes back to watching the queue. Let me paste the code and then describe what I see:

#!/usr/bin/perl

use strict;
use warnings;

use Beanstalk::Client;
use Parallel::ForkManager;

my $clnt = Beanstalk::Client->new({
    server => '127.0.0.1:11300',
    debug => 1,
}) || die "Cannot Connect to Queue Manager";

my $pmgr = Parallel::ForkManager->new(20);

$pmgr->run_on_finish(
    sub {
        my ($pid, $exit_code, $ident) = @_;

        if ($clnt->delete($exit_code)) {
            print "Deleted Job $exit_code\n";
        }
        else {
            print "Error Deleting Job $exit_code: " . $clnt->error . "
+\n";
        }
    }
);

$pmgr->run_on_start(
    sub {
        my ($pid, $ident) = @_;

        if ($clnt->bury($ident)) {
            print "Buried Job $ident\n";
        }
        else {
            print "Error burying Job $ident: " . $clnt->error . "\n";
        }
    }
);

INFINITE_LOOP:
while (1) {

    sleep 5;

    my $job = $clnt->reserve(); #blocks until a message is found in qu
+eue
    if (! $job) {
        print "Error Reserving - Possible Deadline Approaching: " . $c
+lnt->error ."\n";
        next INFINITE_LOOP;
    }
    print "Reserved Job " . $job->id . "\n";
    
    $pmgr->start($job->id) and next;
    sleep 120; # Job work would go here
    $pmgr->finish($job->id);
}

exit;
[download]

When I run this code, here is what I find: (1) When the messages are coming at intervals of say 10 seconds, run_on_finish is never called. (2) After the 10th or 12th message or so, suddenly (no pattern that I can discern) run_on_finish is called repeatedly to reap all 10 (or 12) processes that have ended. (3) Again for about 10/12 messages, no run_on_finish and then suddenly again after 10/12 messages all finished tasks are reaped. Would appreciate if you could help me understand whats going on