snapshot 20050114 race (on list)
Fri Jan 14 19:09:00 GMT 2005
On Fri, Jan 14, 2005 at 01:33:51PM -0500, Pierre A. Humblet wrote:
>the race can come from the self->alert_parent (0);
>in :exit, causing bash to think that the child
>has exited when it's still running.
>There may be a deeper issue, as the timing of Windows
>closing the pipe and "closing" the process is not
>under Cygwin's control.
>There may also be a race (unrelated) between
>setting the state to PID_ZOMBIE in the parent
>and PID_EXITED in the child. This will affect
>sigproc.cc: if (!((terminated = (child->process_state == PID_ZOMBIE)) ||
>I think there is no real need to distinguish between
>PID_ZOMBIE and PID_EXITED.
Actually, there is. I thought about this a lot. I would like to get
rid of both states but they are not identical. The PID_ZOMBIE state
is only valid for situations when the parent has not yet wait()ed for
the child or for when the parent is ignoring SIGCHLD. PID_EXIT just
indicates that the child has exited and the parent, if one exists,
hasn't gotten around to it yet.
While you could just set PID_ZOMBIE in every case, that would mean
that ps would occasionally display a pid as a zombie that wasn't
truly a zombie. I couldn't convince myself that was a good thing.
I also don't see how there can be a race between setting PID_ZOMBIE and
PID_EXITED. PID_ZOMBIE is only set when a child has either already set
PID_EXITED or the child has exited.
I don't understand the other race either. Theoretically cygwin has
closed all handles by the time it has hit pinfo::exit. If there are
still open handles that would indicate a handle leak somewhere, it
More information about the Cygwin-developers