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

I was testing out pid generation behavior on Mac OS X (10.3.4) when I noticed that the child process of a fork() was returning the parent process' parent id (1) instead of its own parent process id. This system is running Perl v.5.8.1RC3 for Darwin.

The behavior happens anywhere from 20-99% of the time, as you can see from the test output below. I was wondering if anyone else has experienced this behavior, I haven't been able to find anything on this via Google, the perldocs, etc.

The script: 
#!/usr/bin/perl
use strict;

my $pid = fork();
die "Can't fork: $!" unless defined $pid;

if ($pid > 0) {
        print "I'm the parent and my pid is $$.  My child is $pid\n";
} else {
        print "I'm the child and my pid is $$.  My parent is " . getpp
+id() . "\n";
}

[download]
And the results: 
$ while true; do perl fork.pl; sleep 1; done
I'm the parent and my pid is 2094.  My child is 2095
I'm the child and my pid is 2095.  My parent is 1
I'm the parent and my pid is 2097.  My child is 2098
I'm the child and my pid is 2098.  My parent is 1
I'm the parent and my pid is 2100.  My child is 2101
I'm the child and my pid is 2101.  My parent is 1
I'm the parent and my pid is 2103.  My child is 2104
I'm the child and my pid is 2104.  My parent is 2103
I'm the parent and my pid is 2106.  My child is 2107
I'm the child and my pid is 2107.  My parent is 1
^C

[download]
Thanks,

-fp

Replies are listed 'Best First'.
Re: Broken getppid() on Darwin/OSX
by Eimi Metamorphoumai (Deacon) on Aug 01, 2004 at 20:09 UTC
    Once a process dies, all of its children get owned by init (process id 1), so I think what you're seeing is that sometimes the parent gets to print out before the child (and then ends its life naturally) and the child moves to 1. And sometimes the child prints first, while the parent is still alive. If you were to add something like a sleep(10) to the parent to keep it alive, you'd probably see consistent results.
[reply]
      Good catch, I think that was it. I guess I was surprised to see that happening on my 1.33 Ghz G4 Powerbook, while I don't see this happening on my dual-P3 1.4Ghz Linux server.

      Thanks!

      -fp
[reply]
        After the fork you've got two different processes vying for the CPU, and which one gets it is undefined behaviour. So it looks like that version of Linux favours the child (I can see some sence in that, since often the child will exec something else anyway and block on IO, while the parent will simply wait for the child). And that version of MacOS doesn't seem to favour either, just throws them both at the scheduler and see what sticks.

        As always with undefined behaviour, if your (not you personally) code depends on it, your code is wrong, even if it happens to work on your particular system on the particular day you tested it on. (For instance, under heavy load it might be entirely different.)

[reply]
Re: Broken getppid() on Darwin/OSX
by Zaxo (Archbishop) on Aug 01, 2004 at 20:14 UTC

    Where the child reports a ppid of 1, the launching parent has already exited. The init process, ppid == 1, has inherited the child.

    (Added) In cases where the child does not get shunted to init, you may be leaving zombies. Run ps and look for processes in Z state. Call wait in the parent to solve both problems.

    After Compline,
    Zaxo

[reply]
Re: Broken getppid() on Darwin/OSX
by superfrink (Curate) on Aug 01, 2004 at 21:20 UTC
[reply]

Back to Seekers of Perl Wisdom