View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001547 | 1003.1(2016/18)/Issue7+TC2 | System Interfaces | public | 2022-01-08 12:14 | 2024-06-11 09:07 |
| Reporter | dannyniu | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | DannyNiu/NJF | ||||
| Organization | Individual | ||||
| User Reference | |||||
| Section | wait, waitid, waitpid | ||||
| Page Number | 2226-2239 | ||||
| Line Number | 70892-71402 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | 0001547:0005739 | ||||
| Summary | 0001547: wait* are cancellation points, but the fate of zombie processes in wait after cancellation are unspecified. | ||||
| Description | While I personally believe, that it's a current best practice that process management should be done in the main thread, we still see many programs call wait in subsidiary threads. I just noticed a problem with the current standard with regard to wait, zombie processes, and thread cancellation. In a normal operation, wait returns the status of child process(es) to the calling thread, but if the thread had been cancelled (assuming deferred cancellation) while the system is processing the wait call, then the fate of exit statuses of zombie processes is not specified in the standard. The biggest problem with the current situation is that, if the wait operation is considered succeeded and the thread is cancelled, then the exit status of the exiting child process may never be known to the parent process, thus lost. | ||||
| Desired Action | There are 3 ways I think this can be solved: 1. Reconsider whether wait* should be cancellation points, 2. Examine existing implementations, and if they're consistent in this aspect, specify wait*'s behavior with regard to thread cancellation and zombie processes, 3. if existing implementations' are inconsistent, specify it as implementation-defined or unspecified behavior, and add a informative text. | ||||
| Tags | tc3-2008 | ||||
|
|
I don't think it's true that "the fate of exit statuses of zombie processes is not specified in the standard". XSH 2.9.5 says: The side-effects of acting upon a cancellation request while suspended during a call of a function are the same as the side-effects that may be seen in a single-threaded program when a call to a function is interrupted by a signal and the given function returns [EINTR]. The side-effect of reaping a zombie process's exit status is not allowed for an EINTR return and is therefore also not allowed on cancellation. |
|
|
I see. I went through the text again, and with `wait*` particularly. In errors, in `wait` and `waitpid`, it said: > [EINTR] > The function was interrupted by a signal. > The value of the location pointed to by stat_loc is undefined. Obviously, it's already undefined pre-pthread for `wait` and `waitpid`. BUT, in `waitid`: > [EINTR] > The waitid() function was interrupted by a signal. Perhaps there should be an addition to `waitid` in this case? |
|
|
On page 2237 line 71357 section waitid(), after:The waitid( ) function was interrupted by a signal.add: The values of the fields of the structure pointed to by infop are undefined. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-01-08 12:14 | dannyniu | New Issue | |
| 2022-01-08 12:14 | dannyniu | Name | => DannyNiu/NJF |
| 2022-01-08 12:14 | dannyniu | Organization | => Individual |
| 2022-01-08 12:14 | dannyniu | Section | => wait, waitid, waitpid |
| 2022-01-08 12:14 | dannyniu | Page Number | => 2226-2239 |
| 2022-01-08 12:14 | dannyniu | Line Number | => 70892-71402 |
| 2022-01-10 10:26 | geoffclare | Note Added: 0005585 | |
| 2022-01-11 01:36 | dannyniu | Note Added: 0005594 | |
| 2022-03-10 17:20 | geoffclare | Note Added: 0005739 | |
| 2022-03-10 17:21 | geoffclare | Interp Status | => --- |
| 2022-03-10 17:21 | geoffclare | Final Accepted Text | => 0001547:0005739 |
| 2022-03-10 17:21 | geoffclare | Status | New => Resolved |
| 2022-03-10 17:21 | geoffclare | Resolution | Open => Accepted As Marked |
| 2022-03-10 17:21 | geoffclare | Tag Attached: tc3-2008 | |
| 2022-05-19 08:37 | geoffclare | Status | Resolved => Applied |
| 2024-06-11 09:07 | agadmin | Status | Applied => Closed |
