View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000788 | 1003.1(2013)/Issue7+TC1 | Base Definitions and Headers | public | 2013-11-07 16:57 | 2013-12-19 17:23 |
Reporter | nick | Assigned To | |||
Priority | normal | Severity | Editorial | Type | Clarification Requested |
Status | Closed | Resolution | Duplicate | ||
Name | Nick Stoughton | ||||
Organization | USENIX | ||||
User Reference | NMS-Zombie-01 | ||||
Section | 3.446 Zombie Process | ||||
Page Number | 105 | ||||
Line Number | 2871-2872 | ||||
Interp Status | --- | ||||
Final Accepted Text | |||||
Summary | 0000788: Definition of Zombie Process unclear | ||||
Description | The current definition of Zombie Process reads: A process that has terminated and that is deleted when its exit status has been reported to another process which is waiting for that process to terminate. This is muddled at best. | ||||
Desired Action | Reword definition on P105 L2871-2872 to: A process that has terminated but has not yet had its exit status reported to another process which is waiting for that process to terminate. | ||||
Tags | No tags attached. |
duplicate of | 0000690 | Closed | clarify behavior when calling waitpid with SA_NOCLDWAIT |
|
Possibly add, to cover the intent of "and that is deleted" in original text: "Residual process specific data maintained until the exit status is reported shall be deleted as part of unblocking the (last?) thread that is waiting on the termination." I added (last?) in case some implementations allow multiple processes to wait on an arbitrary process id, not just the parent process. This could be useful for handling parallel make dependency processing, but a pain to specify both how exit status returned to other than parent and an IPC method to communicate process id from parent to sibling processes. |
|
The deletion of the process is covered in "Consequences of Process Termination". It is not a part of the definition of the term. See Page 549 l19059. The process is NOT deleted until its parent executes wait(), waitid() or waitpid(). However, an implementation MAY free some of the resources associated with a zombie (we don't prohibit that anyway). |
|
That's fine. I agree it's more a consequence than needed to define it. Maybe a "For further details, see [link Page 549]" x-ref is appropriate, for those that may wonder why it's no longer there. |
|
This is already being fixed by 0000690 |
Date Modified | Username | Field | Change |
---|---|---|---|
2013-11-07 16:57 | nick | New Issue | |
2013-11-07 16:57 | nick | Name | => Nick Stoughton |
2013-11-07 16:57 | nick | Organization | => USENIX |
2013-11-07 16:57 | nick | User Reference | => NMS-Zombie-01 |
2013-11-07 16:57 | nick | Section | => 3.446 Zombie Process |
2013-11-07 16:57 | nick | Page Number | => 105 |
2013-11-07 16:57 | nick | Line Number | => 2871-2872 |
2013-11-07 16:57 | nick | Interp Status | => --- |
2013-11-07 19:22 | shware_systems | Note Added: 0001971 | |
2013-11-07 19:32 | nick | Note Added: 0001972 | |
2013-11-07 20:13 | shware_systems | Note Added: 0001973 | |
2013-11-08 10:35 | geoffclare | Note Added: 0001974 | |
2013-11-08 10:35 | geoffclare | Relationship added | duplicate of 0000690 |
2013-12-19 17:23 | geoffclare | Status | New => Closed |
2013-12-19 17:23 | geoffclare | Resolution | Open => Duplicate |