In comp.os.linux.development.system Chris Vine <freeserve.co.uk> wrote:
I recall linus saying that he had changed the order of the first
process to execute after fork twice in the 2.6.0 series. There was some
problem such as you detail below, but it went away ages ago with the
changes made some way back now.
Well, this sounds a bit like the old issue of "who runs first". I
presume this is UP?
Uh huh. Very likely. So? Isn't that allowed? There's nothing wrong with
Well, in fact the handler executes (because the child dies)
before the return value from the fork is known!
It sounds like you should delay setting the handler in the parent till
the fork has returned, but that leaves a window in which the child can
Dunno. I imagine so.
Unknown by me. Compiler issues will intervene to make that cloudy.
Well try a different compiler for a start! Though I don't know if it
will make a difference, since so far life sounds vaguely within spec.
But mapping the space would be useful. Try no optimization.
It makes me nervous not having this static. Shrug. SHouldn't you
declare this volatile too?
So you set the sigchld action to be to tell us what the child_pid is
known to be in the parent process.
Yes, well. Your child dies and activates the handler, but child_pid in
the handler still looks the way it used to be before being assigned by
This sounds as though it's partially a problem with gcc. Can you
scatter a few "volatile"s around, and see if anything changes?