CODEWITHSUNDEEP
csignalssigchld
pankaj kushwaha
pankaj kushwaha

Reputation: 379

Why we generally ignore SIGCHLD

I was studying about signals and going through this link

https://en.wikipedia.org/wiki/Child_process#cite_note-1

And this is what it says : "The SIGCHLD signal is sent to the parent of a child process when it exits, is interrupted, or resumes after being interrupted. By default the signal is simply ignored"

is there any reason why we ignore SIGCHLD.

Upvotes: 1

Views: 3512

Answers (2)

Soner from The Ottoman Empire
Soner from The Ottoman Empire

Reputation: 20911

Even though my answer is late, it might be helpful for a wonderer person thinking reason for need of SIGCHLD and why it is ignored. Let's listen my story.

I've taken a project in which we are streaming online radio stations whose extensions are .pls, .m3u or just IP:Port. Each station is a channel for us. There are two doodads - a potentiometer and a rotary encoder - which are able to be rotated(switched) either clockwise or counter clockwise. The former is used to adjust volume of the radio, likewise the latter is to change channels. I'm using a media player working via terminal, so it is also another process. Likewise, I'm using amixer which is also additional another process to adjust volume abruptly within a while infinite loop . In the main process, I create two processes. To change channel I opt to send SIGKILL signal to terminate the player process which is liable to play selected station to go new channel and wait() in parent. wait() usage is appropriate here because I had killed him before I waited. It would immediately returns without blocking. On the volume changer's side, it works until radio device is turned off. Its process is being run in an infinite loop.

So, what would be happen if I opt to make wait its parent process for the volume adjuster process?

The main process would block forever since the volume adjuster process would never return. In lieu, I opt to handle explicitly but in ignoring way. Why? Because I don't care when it is terminated or what its return value is. I only care that after its termination, I don't want the child to turn into a zombie. I just want when the child exits it is reaped immediately as well as non-blocking main process.

Why do we generally ignore SIGCHLD?

If (as in the aforementioned example) the signal handler does nothing beyond calling waitpid then an alternative is available. Setting the SIGCHLD handler to SIG_IGN will cause zombie processes to be reaped automatically.

Don't forget that to do that, explicitly calling sigaction() with the disposition SIG_IGN is needed.

Upvotes: 1

Brian McFarland
Brian McFarland

Reputation: 9432

Try having kids and you'll understand why sometimes you have to ignore SIGCHLD to maintain your sanity :).

Jokes aside, all that statement means is that POSIX systems do not define a default signal behavior, other than to ignore it, for SIGCHLD. Compare this with SIGINT, SIGTERM, etc where the default behavior might be to terminate the process.

See man 7 signal on linux for a list of all signals, all default handlers, and the mapping of signals->default handler.

Often it makes sense to ignore SIGCHLD because you can know everything you need to know from waitpid.

Upvotes: 6

Related Questions