[Haskell-cafe] Discussion: The CLOEXEC problem
alexander.kjeldaas at gmail.com
Thu Jul 23 06:31:28 UTC 2015
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe