public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/10353] New: Methods for deleting all file descriptors greater than given integer
@ 2009-06-30 23:31 martinrb at google dot com
2009-06-30 23:52 ` [Bug libc/10353] " roland at gnu dot org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: martinrb at google dot com @ 2009-06-30 23:31 UTC (permalink / raw)
To: glibc-bugs
Recent Solaris provides a way to delete all file descriptors
greater than a given integer, and provides a way to ask
posix_spawn to do so. I believe glibc should implement these extensions.
Both of the big programs I have worked on, xemacs and openjdk,
have written their own way to do this.
extern int posix_spawn_file_actions_addclosefrom_np(
posix_spawn_file_actions_t *file_actions,
int lowfiledes);
extern void closefrom(int);
http://docs.sun.com/app/docs/doc/819-2243/posix-spawn-file-actions-addclosefrom-np-3c?l=ja&a=view
http://docs.sun.com/app/docs/doc/819-2243/closefrom-3c?l=ja&a=view
The functionality that has been added to glibc allowing FD_CLOSE_ON_EXEC
to be specified at time of creation of the fd does help (thank you)
but it is not sufficient for "open" programs like the JDK where
arbitrary third party native code may be concurrently opening file
descriptors while creating a subprocess.
--
Summary: Methods for deleting all file descriptors greater than
given integer
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: drepper at redhat dot com
ReportedBy: martinrb at google dot com
CC: glibc-bugs at sources dot redhat dot com
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer
2009-06-30 23:31 [Bug libc/10353] New: Methods for deleting all file descriptors greater than given integer martinrb at google dot com
@ 2009-06-30 23:52 ` roland at gnu dot org
2009-07-01 5:58 ` drepper at redhat dot com
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: roland at gnu dot org @ 2009-06-30 23:52 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From roland at gnu dot org 2009-06-30 23:52 -------
nscd.c does this by hand in a Linux-specific way, and it is trivial to implement
in libc on Hurd. So this seems like a good addition.
--
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer
2009-06-30 23:31 [Bug libc/10353] New: Methods for deleting all file descriptors greater than given integer martinrb at google dot com
2009-06-30 23:52 ` [Bug libc/10353] " roland at gnu dot org
@ 2009-07-01 5:58 ` drepper at redhat dot com
2009-07-01 22:22 ` martinrb at google dot com
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: drepper at redhat dot com @ 2009-07-01 5:58 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From drepper at redhat dot com 2009-07-01 05:57 -------
No, it's a horrible idea. The assumption that a program knows all the open file
descriptors is simply invalid. The runtime (all kinds of libraries) can at any
point in time create additional file descriptors and indiscriminately calls for
trouble. The correct way is to name the individual file descriptors the program
knows about and let the creator of the other file descriptors worry about the rest.
The reason nscd can do it the way it does it is simple: all the code used is
controlled by libc. But that's a special case.
--
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer
2009-06-30 23:31 [Bug libc/10353] New: Methods for deleting all file descriptors greater than given integer martinrb at google dot com
2009-06-30 23:52 ` [Bug libc/10353] " roland at gnu dot org
2009-07-01 5:58 ` drepper at redhat dot com
@ 2009-07-01 22:22 ` martinrb at google dot com
2009-07-02 6:27 ` drepper at redhat dot com
2009-07-02 16:15 ` martinrb at google dot com
4 siblings, 0 replies; 6+ messages in thread
From: martinrb at google dot com @ 2009-07-01 22:22 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From martinrb at google dot com 2009-07-01 22:22 -------
Aside from the Solaris 10 precedent, other OSes have adopted
closefrom, apparently with the same behavior.
Here's OpenBSD:
http://www.openbsd.org/cgi-bin/man.cgi?query=closefrom&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
Here's NetBSD:
http://netbsd.gw.com/cgi-bin/man-cgi?closefrom++NetBSD-current
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,
you fork(), frob some file descriptors you care about,
and then need to close the rest. You write your own buggy closefrom
or use the one provided by the system.
--
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer
2009-06-30 23:31 [Bug libc/10353] New: Methods for deleting all file descriptors greater than given integer martinrb at google dot com
` (2 preceding siblings ...)
2009-07-01 22:22 ` martinrb at google dot com
@ 2009-07-02 6:27 ` drepper at redhat dot com
2009-07-02 16:15 ` martinrb at google dot com
4 siblings, 0 replies; 6+ messages in thread
From: drepper at redhat dot com @ 2009-07-02 6:27 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From drepper at redhat dot com 2009-07-02 06:27 -------
(In reply to comment #3)
> Here's OpenBSD:
> [...]
> Here's NetBSD:
> [...]
This is *anything* but an argument in favor.
> 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.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libc/10353] Methods for deleting all file descriptors greater than given integer
2009-06-30 23:31 [Bug libc/10353] New: Methods for deleting all file descriptors greater than given integer martinrb at google dot com
` (3 preceding siblings ...)
2009-07-02 6:27 ` drepper at redhat dot com
@ 2009-07-02 16:15 ` martinrb at google dot com
4 siblings, 0 replies; 6+ messages in thread
From: martinrb at google dot com @ 2009-07-02 16:15 UTC (permalink / raw)
To: glibc-bugs
------- 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-07-02 16:15 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-30 23:31 [Bug libc/10353] New: Methods for deleting all file descriptors greater than given integer martinrb at google dot com
2009-06-30 23:52 ` [Bug libc/10353] " roland at gnu dot org
2009-07-01 5:58 ` drepper at redhat dot com
2009-07-01 22:22 ` martinrb at google dot com
2009-07-02 6:27 ` drepper at redhat dot com
2009-07-02 16:15 ` martinrb at google dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).