Synchronisation of wait() and kill() #792

What

My understanding of POSIX is as follows:

When a process has terminated, it stays in the kernel's table as a zombie process until the parent has read its exit status using wait(). As soon as wait() returns, the kernel is free to delete the process and reuse its identifier.

Therefore, if we attempt to call kill() after wait(), there is a chance that we kill some completely unrelated process.

Although process identifiers are usually sequential, making this very unlikely, there is nothing which says they must be allocated that way. And even if they are, the point where the number wraps around can be arbitrarily low.

Acceptance Criteria (DoD)

• Use of invalid process identifiers is prevented

How

If my understanding is correct, then we must guarantee that these do not happen simultanously:

• Worker threads calling kill()
• The OS handler calling wait()

If kill() goes first, it will find the zombie process and return ESRCH. We already handle this case properly.

If wait() goes first, and a worker thread is waiting to kill() the same identifier, the worker thread must back out without doing anything.