Ulrich Drepper <drepper@redhat.com> wrote, on 10 Jun 2008:
>
> Geoff Clare wrote:
> > 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.
>
> OK, yes, but the sys/wait.h page says the opposite as well (as I quoted
> already):
>
> WIFSTOPPED
> True if child is currently stopped.
No, that macro is used to decode the status obtained by waitpid() _after_
the function has returned. Its description has no bearing on whether
waitpid() will block or return immediately.
> And this is the only real description of what WIFCONTINUED means. This
> description leaves no doubt that the call should not block since it is
> still stopped.
Again, WIFCONTINUED is only used after waitpid() has returned. The
behaviour of waitpid() itself for continued processes is described under
the WCONTINUED flag on the waitpid() page:
The waitpid() function shall report the status of any continued
child process specified by pid whose status has not been reported
since it continued from a job control stop.
As for WUNTRACED, this clearly requires a second call to block until
the status changes again.
--
Geoff Clare <g.clare@opengroup.org>
The Open Group, Thames Tower, Station Road, Reading, RG1 1LX, England
|