Email List: Xaustin-group-lX
[All Lists]

wait* status definition

To: "austin-group-l@xxxxxxxxxxxxx" <austin-group-l@xxxxxxxxxxxxx>
Subject: wait* status definition
From: Ulrich Drepper <drepper@xxxxxxxxxx>
Date: Mon, 09 Jun 2008 20:21:34 -0700
Organization: Red Hat, Inc.
-----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.  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.


- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkhN8z4ACgkQ2ijCOnn/RHTgqACaAwkB2kH2+nTPv17FhEh7Q39o
uzUAoKhjhyZC4bLfUVM85WM1dPfHgeLV
=jdjx
-----END PGP SIGNATURE-----

<Prev in Thread] Current Thread [Next in Thread>