why waitpid() is good for you

[wje_lf]

Indeed, waitpid() is good for you if you use fork() in your C or C++ program.

This note is inspired by mitchpotter, who wrote in
this thread:

That did it. I used waitpid() and it exited correctly. So I'm guessing a child process will not terminate until the parent calls one of the wait functions. Seems strange but what about Linux isn't.

Mitch has already demonstrated with his code in that thread that he knows the value of checking for errors after every function you call. When he calls fork(), he not only has code which executes in the child (when the returned result is 0) and the parent (when the returned result is neither 0 nor -1); he also checks for error in the fork() call itself (when the returned result is -1).

waitpid() is an extension of this. When you use fork(), the parent process should be curious whether the child process exited with an error, or perhaps because it received a signal which wasn't caught. And that's what waitpid() is for. That's the only reason for the existence of zombie processes. A zombie process is one in which all files have been closed and most other resources have been released, and the only resource left is the exit status from the process. It is kept around until wait() or waitpid() is called from the parent, or the parent itself exits. That's a good thing; you should be interested in what happened to each child process.

Oh. And. mitchpotter? Check the result of that kill(), too, will you? ;)

By the way, mitchpotter shows wisdom when he says:

Threading was an option but became too complicated and I needed something quick and easy.

Threading should be used only when communication between threads is heavy and needs to be optimized. What's worse than having the code become too complicated (though that's quite important) is trying to debug programs which use POSIX threads. Since all the threads share the same heap, if one thread stomps on something it shouldn't, it could be an entirely different thread which shows the symptom. Worse, it could be one thread one time and another thread another time, depending on timing. This makes symptoms of bugs irreproducible. Avoid POSIX threads as long as you can.

[mitchpotter]

Thanks for the followup to my post. I usually close my threads after I figure out what went wrong. Maybe I should leave them open longer.

At any rate, the information here is very helpful and useful in many programs. I've actually now created a class devoted to managing processes using the fork(), execv(), kill(), wait() sequence. Being able to catch the exit value from child processes is useful as well although I don't depend on it because I use monitoring functions for real-time status updates.

[scm]

Thanks for the followup to my post. I usually close my threads after I figure out what went wrong. Maybe I should leave them open longer.

No, much better to close them so no-one else can learn from your experiences.

[wje_lf]

No, much better to close them so no-one else can learn from your experiences.

Well.

1. Other people can still read the content of the thread, so the original poster's experiences are still displayed.
2. If other people have questions or comments, they can simply start a new thread, as I did.
3. Of course, if the original poster changes his mind, he can always unlock the thread.

It turns out that I was not even aware that one could mark one's own thread as solved, thereby locking it. I just assumed that Uebermenschen were coming along and doing that by the authority that accompanies their Uebermenschlichkeit.

That's because I'm mouse-challenged. I'm a command line kinda guy. I don't explore all the options, and if it's not a command line interface, I can't be bothered to read the help stuff unless I have a question.

(Actually, it would, um, help, if there were a help button on each page.)

But the point and click interface is no more intuitive than the command line interface. The only intuitive interface is the nipple.