use Parallel::ForkManager;

  $pm = new Parallel::ForkManager(100);
  my @all_data = qw/1/;
  foreach $data (@all_data) {
    # Forks and returns the pid for the child:
    my $pid = $pm->start; 
    print "PID $pid\n";
    $pid and next;
    print "$data", "\n";
    while(){}; # 100% CPU
    $pm->finish; # Terminates the child process
  }
 $pm->wait_all_children;
[download]

Thanks for looking, it helps level set my next phase of investigation. I will attempt to simplify and retest in my env.

Where did you find the code example you posted? I looked at the written example documentation on cpam and didnt see that version of the code. At any rate I typed in your code and ran it. The PID returned from the fork manager and the PID listed by the system 'top' cmd matched. So I started looking of issues with my specific code. So after investigating my code, I think I have located the issue. I am not sure I have the knowledge to fully explain the technical cause of the issue, but hopefully someone else reading can and will explain.

In your code example, if you replace the line... while () {}; # ie the work item for the child process which in this case is just a forever loop.

replace with .... system("foreverLoop.pl"); # here the foreverLoop.pl file contains the same while() {} code.

and run... you will see the +1 offset in PIDs.

In general my code is attempting to use the forkManager to submit jobs by running external scripts(pl, ksh, etc), so I am using the perl 'system' cmd to start those task. The introduction of the system cmd is causing the PID reported by the forkManager to be 1 less than the PID tracked by the top cmd.

I should have expected this since system probably starts it's own child process. However having said all that I am really not sure how to properly work around this. Is it safe for me to just change the reported PID by +1 or is there a better way? I am just not sure if the +1 offset is a for sure thing or if the actual offset is subject to system timing?