snapshot 20050114 race (on list)
Pierre A. Humblet
Sat Jan 15 01:17:00 GMT 2005
At 02:41 PM 1/14/2005 -0500, Christopher Faylor wrote:
>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.
The more I think about it, the less I see why you don't get rid of it.
PID_EXITED is a transient state into or out of PID_ZOMBIE. From a user
interface point of view, it doesn't matter if PID_EXITED is shown as zombie,
the result might well be correct one ms earlier or later.
Internally Cygwin doesn't care either, except in one spot in sigproc.cc
(see original mail in thread). But even there merging the states won't hurt.
More information about the Cygwin-developers