[Haskell-cafe] Discussion: The CLOEXEC problem

[Donn Cave]

Quoth Bardur Arantsson <spam at scientician.net>,
> 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