quoth Niklas_Hambüchen,
>> do that, you set up the conditions for breaking something that
>> works in C, which I hate to see happen with Haskell.
>
> While I understand your opinion here, I'm not sure that "breaking
> something that works in C" is the right description. O_CLOEXEC changes a
> default setting, but does not irrevocably disable any feature that is
> available in C.

Sure, it isn't irrevocable - so what's broken may be fixed, if you
have access to it, but of course it's better not to break things
in the first place.

> In other words, CLOEXEC is something that is easy to *undo* locally when
> you don't want it, but hard to *do* globally when you need it.

Yes, of course, I understand the appeal.  But it's a deep change
to the way FDs have historically worked that affects widely used
UNIX features, and it doesn't solve the problem - sockets, file
descriptors created by external libraries or inherited from the
parent process, child processes that don't exec - so if you want
to relieve a child process of all extraneous open files, you still
have to walk the FD table, the sam way it's been done for the last
20 or 30 years.  Fork-exec is the relatively unusual event where
it makes sense to deal with these issues - including other resources
besides FDs as required.  Fork-exec outside of GHC should of course
continue to work as written.