> Another simpler approach, but not as efficient, is to iterate over /proc/$$/fd and close all
of the open file descriptors listed there.
I believe that this is a standard approach, and indeed one that udrepper advocates in other
cases. (Arguably a single-syscall approach would be cleaner, to avoid the dependency on
having /proc mounted at a well-known location, but it's hard for me to imagine that efficiency
is really an issue here -- it's not like reading /proc will hit the disk, so the overhead is
just a few extra syscall entries.) Certainly this is useful functionality to have.
But you seem to arguing that -- since we have this other useful functionality -- close-on-exec
becomes a useless feature that would be better to ignore than to fix, while I would tend to
think that working close-on-exec and efficient closefrom are both valuable. It would be
easier to evaluate your argument if you addressed this point directly. 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.
If you don't have close-on-exec, then working out *which* descriptors should remain open and
which should remain closed requires long-distance coupling between the fork/exec code and all
code which creates file descriptors. Do you disagree?