Getting return code from a child process

[Jon]

How do I get the return value of a child process? Take this example:

====================================
sub my_function {
return 10;
}

my $return=0;
my $child_pid=0;
if (!defined($child_pid = fork())) {
die "cannot fork: $!";
} elsif ($child_pid) {
# I'm the parent
} else {
# I'm the child
$return = my_function();
print("return is $return\n");
exit 0;
}

my $pid = wait;
print("return is $return\n")
==========================================

Output is:
return is 10
return is 0

The wait() function returns the pid and what I really want is the
return code from that pid. I would like to pass the return code of a
function I ran in the child back to the parent...Is there a simple way
to do this? I *think* there might be a way to do this with pipes, but
I have no clue as to how to do that.

Thanks for any help,

Jon

 

[Ben Morrow]

The wait() function returns the pid and what I really want is the
return code from that pid.

What this appears to be asking for is the '0' out of 'exit 0'; you can
get that with $? >> 8 after a successful wait(). See perlvar.

I would like to pass the return code of a
function I ran in the child back to the parent...Is there a simple way
to do this?

If the value you wish to return is an integer between 0 and 255,
inclusive, you can pass it to exit in the child and retreive it as
above in the parent. If it is anything more complicated than that, you
have basically two options:

1. Use threads instead of processes. You'll want 5.8 for this; start
by reading perldoc perlthrtut.

I *think* there might be a way to do this with pipes, but
I have no clue as to how to do that.

2. Pass the data back from child to parent in a pipe. You need to
decide on some format for your data: if there are no other
considerations, Storable provides a compact representation of
'most any Perl data structure. The way you would do this would be
something like (this is completely untested and written straight
off the top of my head):

use Storable qw/store_fd fd_retrieve/;

my $kid = fork;
defined $kid or die "fork failed: $!";

pipe my $FROM, my $TO;

if($kid) {
close $TO;
# parent
} else {
close $FROM;
my $return = my_function();
store_fd \$return, $TO; # you have to store a reference
exit 0;
}

my $return = fd_retrieve $FROM or die "fd_retrieve: $!";
$return = $$return; # de-ref the reference
close $FROM;

Read the docs for Storable to see what you can send and how to send it.

Ben

 

[Jon]

Ben & Jim,

Thanks guys. You gave me some great information. I can do what I need to do now.

Jon

 

[Peter Dintelmann]

Hi Jon,

Ben & Jim,

Thanks guys. You gave me some great information. I can do what I need to

do now.

and please have an additional look at the macros
WIFEXITED and WEXITSTATUS from the POSIX
module (they make code much more readable then
"$? >> 8").

Peter

 

[Anno Siegel]

[question from Jon about getting return code from child process snipped]

2. Pass the data back from child to parent in a pipe. You need to
decide on some format for your data: if there are no other
considerations, Storable provides a compact representation of
'most any Perl data structure. The way you would do this would be
something like (this is completely untested and written straight
off the top of my head):

use Storable qw/store_fd fd_retrieve/;

my $kid = fork;
defined $kid or die "fork failed: $!";

pipe my $FROM, my $TO;

if($kid) {
close $TO;
# parent
} else {
close $FROM;
my $return = my_function();
store_fd \$return, $TO; # you have to store a reference
exit 0;
}

my $return = fd_retrieve $FROM or die "fd_retrieve: $!";
$return = $$return; # de-ref the reference
close $FROM;

While I am loathe to question the answers of others, shouldn't one

You must be new around here

create the pipe _before_ doing the fork so that both parent and child
process are using the same anonymous pipe?

Correct. The way it is, parent and kid each open their own pipe,
which have nothing to do with each other. Thus fd_retrieve complains
in the parent when the pipe returns nothing.

Moving "pipe" three lines up fixes that.

Correcting erroneous answers is a public service, and no regular will
take offense. That goes for all technical newsgroups. It is comforting
to know that code that passes through the group is thoroughly scrutinized.

Anno