passing string/refs to run_on_finish with Parallel::ForkManager

digdoug has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks,
Apologies if this question is deemed absurd, but can someone tell me why I am not able to pass a string or reference to the run_on_finish sub?

This code:

#!usr/bin/perl

use Parallel::ForkManager;

my $MAX_PROCESSES=10;

$pm = new Parallel::ForkManager($MAX_PROCESSES);

$pm->run_on_finish(
    sub {
      my ($pid, $exit_code, $ident, $signal, $core) = @_;
      print "$pid $exit_code $ident $signal $core\n";
    }
  );

foreach ( a .. f ) {
  my $pid = $pm->start($_) and next;
  my $exit_code = 40;
  $pm->finish($exit_code);
}
[download]

predictably produces this:

20151 40 a 0 0
20152 40 b 0 0
20153 40 c 0 0
20154 40 d 0 0
20155 40 e 0 0
[download]

change:

  my $exit_code = 40;
[download]

  my $exit_code = 'forty';
[download]

and you get:

20963 0 a 0 0
20965 0 c 0 0
20966 0 d 0 0
20967 0 e 0 0
[download]

or:

  my $exit_code = \'forty';
[download]

and you get:

22040 192 a 0 0
22041 192 b 0 0
22042 192 c 0 0
22043 192 d 0 0
22044 192 e 0 0
[download]

Just wondering.
There are other ways to do what I need to do (of course, it's Perl) but I'd love to know what is happening here.
D

Comment on passing string/refs to run_on_finish with Parallel::ForkManager Select or Download Code

Replies are listed 'Best First'.
Re: passing string/refs to run_on_finish with Parallel::ForkManager by Fletch (Bishop) on Apr 18, 2007 at 17:45 UTC
Most obvious guess is that `$exit_code` is expected to be a number, not a string. When Perl gets `'forty'` in a numeric context it becomes 0; when it gets your reference `\'forty'` it just happened to reside at an address who's lower octet was 192. Your `run_on_finish` is just receiving the aftermath of that numerification of the value.	[reply] [d/l] [select]
Re: passing string/refs to run_on_finish with Parallel::ForkManager by derby (Abbot) on Apr 18, 2007 at 18:29 UTC
Fletch is correct. Parallell::ForkManager just calls exit which eventually calls the underlying C library exit which accepts an int as a parameter. Traditionally 0 is for success and non-zero is failure. That being said, there's tons of apps out there that do more than return 1 -- it's up to you as the dev to map the integer exit value with some meaning. -derby	[reply]
Re: passing string/refs to run_on_finish with Parallel::ForkManager by Moron (Curate) on Apr 18, 2007 at 19:50 UTC
Registers are used primarily to hold addresses rather than data (which is more often kept in RAM), but exit codes are a special case because when a program has exited, it has cleared out of its addressing space (update: or at least is deemed to have done so by convention at a low level of operating system design) leaving only the conventional register to communicate with the shell. Thus exit codes irrespective of what language the program might be written in are limited by operating system conventions to what can fit into a register - usually max 64 bits these days although the exact implementation is likely to have its roots in the first implementation of Unix on a 16 bit machine. At that point in time (early 1970s) the machine was the PDP-11. Its registers were numbered R0 to R11 and the exit code of any program was placed in R0, a sixteen bit register to be picked up after exit by the shell. __________________________________________________________________________________ ^M Free your mind!	[reply]