Re: wait* status definition

[Michael Kerrisk <mtk.lists@xxxxxxxxx>]

Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I got asked a question to which I cannot give a definitive answer.
>
>
> 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
>
>
> I think the former is right and the next status to return is
> WIFCONTINUED.  
Agreed.

> Why else should there by WIFCONTINUED.
> But:
>
> - - WIFCONTINUED is an XSI option
>
> - - the exact description for WIFSTOPPED is
>
>            True if child is currently stopped
>
>   This seems to imply that the state information is sticky and should
>   be re-reported.
>
>
> I guess the final answer depends on historic practice.  Linux does the
> latter, it returns immediately.
I just tested waitpid() and waitid() on Linux.  I don't see the behavior 
you're talking about.  Did you have some code that demonstrates the 
phenomenon?

Cheers,

Michael