snapshot 20050114 race (on list)

Christopher Faylor
Fri Jan 14 19:41:00 GMT 2005

On Fri, Jan 14, 2005 at 02:33:21PM -0500, Pierre A. Humblet wrote:
>Christopher Faylor wrote:
>>>I think there is no real need to distinguish between PID_ZOMBIE and
>>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.
>You are right, there is no race there.  Sorry for the noise.  Most
>places in Cygwin (e.g.  ps) don't seem distinguish between ZOMBIE and
>EXITED, but fhandler_process does.  Perhaps ps should too.

Huh.  I never looked at ps.

It probably should distinguish between a zombie and an exited process
somehow.  I'd almost think that it shouldn't display an exited process
except that there is a race between the setting of exited and the
setting of zombie.

Just to clarify: When I said I would like to get rid of both states, I
was wrong.  I really meant I'd like to get rid of PID_EXITED.  I have
started down that path several times, ripped out the define, gotten rid
of the special case handling, and always ended up putting it back.

One thing that kept occurring to me was that if exitcode is !=
EXITCODE_UNSET the the process has exited and you don't need to check
PID_EXITED.  Adding that kind of check didn't seem to simplify the
code any, though.


More information about the Cygwin-developers mailing list