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. Donn