snapshot 20050114 race (on list)

Christopher Faylor
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
>  if (!((terminated = (child->process_state == PID_ZOMBIE)) ||
>I think there is no real need to distinguish between

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 mailing list