[Bug libc/10353] Methods for deleting all file descriptors greater than given integer

["martinrb at google dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From martinrb at google dot com  2009-07-02 16:14 -------

>> To provide more motivation, the idea is that you are in a
>> large multithreaded app that is swimming in a sea of unknown
>> file descriptors that may or may not have FD_CLOEXEC set,

>So, fix the code.  We have O_CLOEXEC support as well.  There is no reason to
>work around buggy code and this interface *actively* prevents innovations by
>usurping file descriptors.

For many applications, there is no way in practice to control all the 
code running in the same address space.  This is especially true for
"platforms" like java, where arbitrary user-created shared libraries
are loaded and executed at runtime.

The idea of permitting innovations that use file descriptors is
an interesting one, but one that in my opinion cannot succeed.
Too many people (like myself) are maintaining library code
that starts new subprocesses, and they will continue to
indiscriminately close unknown file descriptors, 
with or without help from their libc.

While my library closes file descriptors unconditionally,
The python subprocess API makes closing fds an option.

"""If close_fds is true, all file descriptors except 0, 1 and 2 will be
closed before the child process is executed."""

Interestingly, python provides a related function

.. function:: closerange(fd_low, fd_high)

   Close all file descriptors from *fd_low* (inclusive) to *fd_high* (exclusive),
   ignoring errors. Availability: Unix, Windows. Equivalent to::

      for fd in xrange(fd_low, fd_high):
          try:
              os.close(fd)
          except OSError:
              pass

which doesn't seem to support "infinity" for the second argument.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10353

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.