0

These are from the documentation on waitpid() https://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html

About the pid parameter

If pid is greater than 0, it specifies the process ID of a single child process for which status is requested.

About the return value

waitpid() returns because the status of a child process is available, these functions shall return a value equal to the process ID of the child process for which status is reported.

From this, I expect that if I pass a positive int (pid) I should get the same number as the return value.

I am observing that in some cases when I call waitpid() with a positive integer representing a pid with no other option parameters (the third paraeter is 0), the call returns another integer which is not equal to the pid passed in (although it is close in value).

So, when does waitpid() call return a value different from the the pid (>0) passed?

Edit 1:

The call looks like this: waitpid(pid, &status, 0)

pid is an int (>0) status is an int

In some of the runs the value of PID passed and returned are different: (In the below lines a!=b where a is the return value, b is the PID passed to waitpid() )

2019-11-21, 09:38:11.573007 [info] - WAITPID CALL: 16881!= 16890
2019-11-21, 09:38:11.573007 [info] - WAITPID CALL: 16881!= 16890
2019-11-21, 09:39:11.149065 [info] - WAITPID CALL: 17087!= 17096
2019-11-21, 09:41:11.570292 [info] - WAITPID CALL: 17433!= 17442
2019-11-21, 09:43:11.373236 [info] - WAITPID CALL: 17761!= 17770

This behavior is not consistent but happens once in a few runs.

HoldOffHunger
  • 18,769
  • 10
  • 104
  • 133
Shreyas Panduranga
  • 5
  • 3
  • 1
    `waitpid()` requires three arguments; what did you mean by "no other option parameters"? When `waitpid()` is called with *pid* > 0, it can return *pid*, or 0 if WNOHANG was set in *options* and the child has not changed state, or −1 on error. No other return value is possible. If you have a counterexample, please include it in the question. – AlexP Nov 21 '19 at 11:03
  • 1
    Make sure you're assigning the result to a signed integer, otherwise it will always be >0 – Barmar Nov 21 '19 at 11:10
  • @AlexP I meant the third parameter (int options) was passed as 0. – Shreyas Panduranga Nov 21 '19 at 11:17
  • @Barmar I am using signed integers. – Shreyas Panduranga Nov 21 '19 at 11:23
  • Please, include to the question the **exact** code you use for test. It could be that your test is simply wrong. – Tsyvarev Nov 21 '19 at 13:04

0 Answers0