Quoth Bardur Arantsson
On 07/24/2015 09:22 PM, Donn Cave wrote: ...
If recently means less than a decade or so, though, it's not much to go on. If the problem addressed by the O_CLOEXEC proposal is obscure, the problems it may create are even more so - I'll certainly concede that - and it could take a lot of experience before those problems would be well known enough to show up if you went looking for them.
It seems to me that discovering a "FD-was-unexpectedly-closed-before-it-was-supposed-to" problem is a lot more likely than discovering FD leaks, no?
Maybe ... Note that if it were exactly about FD leaks, that problem would be undiscovered yet. The reason anyone cares is that the leaked file descriptor may go on to inconveniently hold a file open. In what I think is the most common case, the file is a pipe, and the open write end makes a read hang when it should complete. Pipes aren't created by open(2) so won't be part of an O_CLOEXEC solution, but I imagine this is where the issue is usually first encountered, and why popen(3) closes all file descriptors. With disk files ... off the top of my head, the most likely effect might NOT be read/write I/O errors, because here we're talking about passing a file descriptor value through an exec, which I think is an unusual programming practice. It's easy enough to do, e.g. you can format the value into a shell command like "echo whatever >&6", but eccentric. But there are other things that could turn up. For example, you could use flock(2) (Berkeley, not POSIX fcntl lock) to keep an advisory file lock until the exec exits. If the file is closed prematurely, you lose the lock, and ... whatever happens then. Donn