[Haskell-cafe] Discussion: The CLOEXEC problem

[Alexander Kjeldaas]

On Thu, Jul 23, 2015 at 3:23 AM, Donn Cave <donn at avvanta.com> wrote:

> 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.
>
>
This history is from before the c10k problem and related file descriptor
scaling became relevant.

Yes we need to walk the open file descriptors by walking /prod/self/fd and
using obscure APIs on OS X.  No matter how you see it, it's not what it was
30 years ago.

Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150723/51f3583f/attachment.html>