RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close()

Martin Buchholz martinrb at google.com
Tue Sep 18 01:24:24 UTC 2018


More concurrent discussion over in libc-alpha
"""system and popen fail in case of big application"""
http://sourceware-org.1504.n7.nabble.com/system-and-popen-fail-in-case-of-big-application-tt534908.html#a537069

On Wed, Sep 12, 2018 at 6:17 AM, Martin Buchholz <martinrb at google.com> wrote:
> In 2018, we can assume everyone has implemented FD_CLOEXEC.
>
> Back in 1970, 20 file descriptors was enough for any program, but
> today they're effectively unlimited, so futilely closing _SC_OPEN_MAX
> descriptors has become unreasonable (as you say).  OTOH, there is
> still no standard way of ensuring all our file descriptors are closed.
> Do we need the fallback on your beloved HP-UX?  Should we simply close
> the first 64k file descriptors and pray, as is traditional?
>
> freebsd offers closefrom(2)
> https://www.freebsd.org/cgi/man.cgi?query=closefrom&sektion=2&manpath=freebsd-release-ports
> and today we can autoconfiscate the existence of closefrom and use
> that where available (BSD and Solaris?)
>
> closeDescriptors needs a better name now - maybe ensureDescriptorsAreClosed ?
>
> I'd give this function a javadoc style docstring.
>
> (Finding the FD_DIR directory has become rather ugly, especially the
> AIX-specific code)


More information about the core-libs-dev mailing list