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?

Where did you find the code example you posted?

I edited first example (in SYNOPSIS) here.

I should have expected this since system probably starts it's own child process.

Exactly!

or if the actual offset is subject to system timing?

yep.

having said all that I am really not sure how to properly work around this.

Why do you need exactly the PID which do the work?

in general this problem is hard to solve..
You can use something like this:

  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";

    my $pid2 = fork();
    unless ($pid2) {
      exec $^X, '-e', 'while(){}';
    }
    print "Real PID $pid2\n";
    waitpid $pid2, 0;


    $pm->finish; # Terminates the child process
  }
 $pm->wait_all_children;
[download]

i.e. use "exec", "fork" and "wait/waitpid" calls.

Note that I don't recommend putting it into production until you fully understand how those functions works.
Also this example won't work if you replace

exec $^X, '-e', 'while(){}';
[download]

with

exec "perl -e 'while(){}'";
[download]

those calls are equivalent, but former calls PERL, and later one calls SHELL, which will call PERL.
so with later one you'll get wrong pid again (PID of shell)

Also, you really cannot control if scripts, that you call are calling other scripts or other processes or no

Thus this task is hardly solvable.

I propose explain you business requirements (exactly why you need that PID who do works) and someone might suggest something.

or if the actual offset is subject to system timing?

On more secure systems, the pid is picked randomly, not sequentially. I didn't think anyone still did sequential pids! What system are you using?