Question: Does a race condition exist in the "Into the woods" implementation?

[ramr]

Question: Does a race condition exist in the "Into the woods" implementation?

[ajones-miovision]

Ok, so i wrote a small c program that tries to replicate the issue and it seems like both waits will return so my assumption that one would get stuck waiting forever is false. They will both return but only one will receive the exit status.

[ramr]

Cool - am glad you figured it out.

Yeah, in your example with the parent wait[4] code executing after the child exits (Note: exited but not terminated) ... the exit of the child process leaves it in a "waitable" state, so a subsequent wait* call would return the child status information.

The *nix rationale being something akin to a parent should be free to do some other work ("chores") whilst the child is playing and come back and clean up afterwards!

Note that if the child process is never wait[ed] on aka never cleaned up, you'll end up with a zombie process.

And also note that wait [wait{2,4} are wrappers] could return if the child process has changed "state" .. this is terminated in your case but it could well be a suspend-continuation workflow ... aka sig{stop,tstp,cont}. Hence the check for ECHILD if the syscall wasn't interrupted.