Signals in fork

What is signal behavior in the fork. Should all signals are inherited in fork If not then which one a开发者_高级运维nd why?

---

At least under Linux, signal handlers themselves are inherited but not the pending signals.

Quoting the Linux fork(2) man page:

fork() creates a child process that differs from the parent process only in its PID and PPID, and in the fact that resource utilizations are set to 0. File locks and pending signals are not inherited.

This makes sense since the signals belong to the (parent) process. The newly created process is (mostly) a copy of the current process so signal handlers are preserved.

Although not directly related, the exec()-type call that often follows a fork() will destroy all signal handlers since a brand new executable is being loaded into the process (overwriting the functions currently servicing signals).

---

I will go with the paxdiablo answer that the pending signals are reinitialized, though the signal handler are copied. Here a snipped from the kernel source code in do_fork that actually do the forking on behalf of the process.

/*do_fork(...)*/
spin_lock_init(&p->alloc_lock);

init_sigpending(&p->pending);// reinitializing the pending signals

---

But to be absolutely sure that your code is portable and consistent on all platforms its better to check the behaviour of signals that are likely to affect your program execution.While linux guarantees so,implementations are free to chose the way they want to implement.sigaction can come in handy for the same.