Messages in this thread | | | Date | Wed, 30 May 2007 12:55:47 -0700 | From | Ulrich Drepper <> | Subject | Re: Syslets, Threadlets, generic AIO support, v6 |
| |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Davide Libenzi wrote: > An application > linking to glibc can break glibc in thousand ways, indipendently from fds > or not fds.
It's not (only/mainly) about breaking. File descriptors are a resources which has to be used under the control of the program. The runtime cannot just steal some for itself. This indirectly leads to breaking code. We've seen this many times and I keep repeating the same issue over and over again: why do we have MAP_ANON instead of keeping a file descriptor with /dev/null open? Why is mmap made more complicated by allowing the file descriptor to be closed after the mmap() call is done?
Take a look at a process running your favorite shell. Ever wonder why there is this stray file descriptor with a high number?
$ cat /proc/3754/cmdline bash $ ll /proc/3754/fd/ total 0 lrwx------ 1 drepper drepper 64 2007-05-30 12:50 0 -> /dev/pts/19 lrwx------ 1 drepper drepper 64 2007-05-30 12:50 1 -> /dev/pts/19 lrwx------ 1 drepper drepper 64 2007-05-30 12:49 2 -> /dev/pts/19 lrwx------ 1 drepper drepper 64 2007-05-30 12:50 255 -> /dev/pts/19
File descriptors must be requested explicitly and cannot be implicitly consumed.
All that and the other problem I mentioned earlier today about auxiliary data. File descriptors are not the ideal interface. Elegant: yes, ideal: no. Fro physics and math you might have learned that not every result that looks clean and beautiful is correct.
- -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGXdbC2ijCOnn/RHQRAgBbAJ0RoNsQr4L6Bm5hLy7somAKeTqCcQCbBHmx 8hzG+1w0rYMTqXxNmi/QQ7o= =O7Xm -----END PGP SIGNATURE----- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |