pdfork(2) has semantics very close to what we want in forkfd, but not
quite. Differences:
- we still get SIGCHLD and need to do a wait4
- no support for atomic FD_CLOEXEC and O_NONBLOCK
On the SIGCHLD case: this commit is an improvement over the generic Unix
case, since we no longer need to install a SIGCHLD handler and do not
need to keep the arrays for matching PIDs and file descriptors. That
matching is done entirely inside the kernel.
However, since SIGCHLD is still sent to the process, an uncooperative
SIGCHLD handler can still "steal" our response. At least Glib is
documented not to reap children it wasn't explicitly asked to watch for
(source code matches), but other libraries are known to do waitpid(-1)
(e.g., EFL's Ecore). At least now the behavior is consistent: we will
never install a handler, so the behavior won't depend on the order in
which the handlers are installed.
Change-Id: Iee8cbc07c4434ce9b560ffff13cb4c63306e43ef
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
0ec809e027