Ulrich Drepper <drepper@redhat.com> wrote, on 09 Jun 2008:
>
> Assume process A waits for process B (waitpid, waitid, ...)
>
> Process B is stopped (by itself or a third process)
>
> Process A wakes up and is signalled WIFSTOPPED
>
> Now process A calls wait* again.
>
>
> What is this call supposed to do? There are two possible
> interpretations of the standard:
>
> - - status information is the change from running to stopped. This
> information has been communicated in the first wait* call and
> therefore the second call will block
>
> - - the status of the child is still stopped and therefore the call
> will immediately return and signal WIFSTOPPED again
For waitpid() the answer lies in the description of the WUNTRACED flag
on the waitpid() page:
The status of any child processes specified by pid that are
stopped, and whose status has not yet been reported since they
stopped, shall also be reported to the requesting process.
It is clear from this that the second call will block.
Unfortunately the waitid() page is less clear. The key there is the
WNOWAIT flag:
Keep the process whose status is returned in infop in a waitable
state. This shall not affect the state of the process; the process
may be waited for again after this call completes.
This description implies that when the flag is clear, the process
is no longer "in a waitable state" after the waitid() call; meaning
status information will not be available until it changes state again.
It is probably worth clarifying the waitid() page in TC1.
--
Geoff Clare <g.clare@opengroup.org>
The Open Group, Thames Tower, Station Road, Reading, RG1 1LX, England
|