Re: Broken getppid() on Darwin/OSX

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.

Comment on Re: Broken getppid() on Darwin/OSX

Replies are listed 'Best First'.
Re^2: Broken getppid() on Darwin/OSX by fuzzyping (Chaplain) on Aug 01, 2004 at 20:12 UTC
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]
Re^3: Broken getppid() on Darwin/OSX by Eimi Metamorphoumai (Deacon) on Aug 02, 2004 at 13:08 UTC
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]