File descriptor handling changes in 2.6.27
Posted Aug 6, 2008 22:13 UTC (Wed) by quotemstr
In reply to: File descriptor handling changes in 2.6.27
Parent article: File descriptor handling changes in 2.6.27
the nominal benefit of
close-on-exec is that it allows locality of control -- the code that creates the fd is (often)
the code that is best prepared to know whether it should be kept local to the process or not.
I disagree with the locality of control argument. In a well written program, any code which creates a file descriptor to be inherited across an exec boundary ought to be intimately tied to that exec: consider shell pipeline setup. A piece of code unrelated to that exec (say, X11, or the DNS resolver) should not expect its file descriptors to propagate across an exec.
However, not all libraries will hygienically mark their internal file descriptors as close-on-exec. So, in a well-written program:
- Code unrelated to an exec SHOULD mark internal file descriptors with O_CLOEXEC.
- fork/exec code MUST close all extraneous file descriptors, as not every library will obey rule #1
to post comments)