Re: Syslets, Threadlets, generic AIO support, v6

[Ulrich Drepper <drepper@redhat.com>]

-----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/