Comment 46 for bug 159258

(In reply to comment #41)
> (2) portable: after fork() use dup2 to set up stdin/out/err then
> getrlimit(RLIMIT_NOFILE) and iterate for (int i = 2; i < N; ++i) { close(i); }

This would be best to watch out for race conditions too.
N could be large, but /proc/PID/fd could be an optimization I guess.

>
> (3) not portable: linux (and perhaps others) is slowly acquiring O_CLOEXEC,
> F_DUPFD_CLOEXEC and other such flags so that you can cause fds to be created
> with F_CLOEXEC set from the start.

This seemed ideal to me (and a portable library seemed the best way to decide
whether to use this) but I guess this is only going to help with open, not all
the fd creation functions.

>
> imho (2) is the best solution.

I'm thinking this might be easiest.

If an external helper process like tenthumbs suggests is used, it wouldn't
need to worry about race conditions. And once its a separate process, doing a
little work to close file descriptors is not a significant issue.

If we were already using the IPC daemon then that would seem the way to go.
If this or a similar daemon was launched early enough, then it would avoid the
problem of being unable to fork when using more than half the available
virtual memory (http://www.cmiss.org/cm/tracker/227/). But maybe that's for
the future.

> you just have to catch all uses of fork().
> i.e. popen() is hell.

:-) I'm hoping we are not using popen.