Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001547 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Clarification Requested 2022-01-08 12:14 2022-01-11 01:36
Reporter dannyniu View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name DannyNiu/NJF
Organization Individual
User Reference
Section wait, waitid, waitpid
Page Number 2226-2239
Line Number 70892-71402
Interp Status ---
Final Accepted Text
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 No tags attached.
Attached Files

- Relationships

-  Notes
(0005585)
geoffclare (manager)
2022-01-10 10:26

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.
(0005594)
dannyniu (reporter)
2022-01-11 01:36

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?

- Issue History
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


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker