[GHC] #14143: forkProcess leaks file descriptors
GHC
ghc-devs at haskell.org
Tue Aug 22 06:27:57 UTC 2017
#14143: forkProcess leaks file descriptors
-------------------------------------+-------------------------------------
Reporter: danharaj | Owner: (none)
Type: feature request | Status: new
Priority: normal | Milestone:
Component: libraries/base | Version: 8.2.1
Resolution: | Keywords:
Operating System: POSIX | Architecture:
| Unknown/Multiple
Type of failure: Other | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by svenpanne):
This one seems to be a *nix classic... :-} Basically the same issue has
been discussed e.g. here
https://sourceware.org/bugzilla/show_bug.cgi?id=10353. Although I'm not a
big fan of Ulrich Drepper, I think he is right in this case: You simply
can't know which FDs are open for what reason, at least you can't if you
use any kind of external library. The GHC RTS is just one kind of such
library, and having some hook for it doesn't solve the problem in general.
What about (native) libraries you use? Would it be correct to simply close
their FDs or not? One can't know.
I think the main problem is that the default for open() is wrong: Normally
you do not want to pass down FDs to subprocesses, so O_CLOEXEC should be
the default IMHO. In the rare case that the application/library wants an
FD to stay open, it should say so explicitly. BTW: What about the
O_CLOEXEC flag for the FDs behind Haskell's Handles? Is it on or off? Do
we really have the right default?
I might be oversimplifying some things here, but given the *nix history,
this is a hard problem, and I consider any library closing FDs it doesn't
own buggy.
Just my 2c... :-)
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14143#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list