signalfd.2: signalfd() doesn't play well with helper programs spawned by libraries

See https://lwn.net/Articles/415684/.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

man2/signalfd.2

@@ -351,6 +351,26 @@ or the
 .BR SIGFPE
 signal that results from an arithmetic error.
 Such signals can be caught only via signal handler.
+
+As described above,
+in normal usage one blocks the signals that will be accepted via
+.BR signalfd ().
+If spawning a child process to execute a helper program
+(that does not need the signalfd file descriptor),
+then, after the call to
+.BR fork (2),
+you will normally want to unblock those signals before calling
+.BR execve (2),
+so that the helper program can see any signals that it expects to see.
+Be aware, however,
+that this won't be possible in the case of a helper program spawned
+behind the scenes by any library function that the program may call.
+In such cases, one must fall back to using a traditional signal
+handler that writes to a file descriptor monitored by
+.BR select (2),
+.BR poll (2),
+or
+.BR epoll (7),
 .\"
 .SS C library/kernel differences
 The underlying Linux system call requires an additional argument,