Let's get started with the flag SA_NOCLDWAIT. First, a quick digression:

As we learned in Chapter 10, Process Creation, a process can fork, resulting in an act of creation: a new child process is born! From that chapter, it is now relevant to recall our Fork Rule #7: The parent process must wait (block) upon the termination (death) of every child, directly or indirectly.

The parent process can wait (block) upon the child's termination via the wait system call API set. As we learned earlier, this is essential: if the child dies and the parent has not waited upon it, the child becomes a zombie—an undesirable state to be in, at best. At worst, it can terribly clog system resources. 

However, blocking upon the death of the child (or children) via the wait API(s) causes the parent to become synchronous; it blocks, and thus, in a sense, it defeats the whole purpose of multiprocessing, to be parallelized. Can we not be asynchronously notified when our children die? This way, the parent can continue to perform processing, running in parallel with its children.

Ah! Signals to the rescue: the OS will deliver the  SIGCHLD signal to the parent process whenever any of its children terminate or enter the stopped state. 

Pay attention to the last detail: the SIGCHLD will be delivered even if a child process stops (and is thus not dead). What if we do not want that? In other words, we only want the signal sent to us when our children die. That is precisely what the SA_NOCLDSTOP flag performs: no child death on stop. So, if you do not want to get spoofed by the stopping of the children into thinking they're dead, use this flag. (This also applies when a stopped child is subsequently continued, via the SIGCONT).