On Wed, 30 May 2007, Eric Dumazet wrote:
> >
> > No, Davide, the problem is that some applications depend on getting
> > _specific_ file descriptors.
>
> Fix the application, and not adding kernel bloat ?
No. The application is _correct_. It's how file descriptors are defined to
work.
> Then you can also exclude multi-threading, since a thread (even not inside
> glibc) can also use socket()/pipe()/open()/whatever and take the zero file
> descriptor as well.
Totally different. That's an application internal issue. It does *not*
mean that we can break existing standards.
> The only hardcoded thing in Unix is 0, 1 and 2 fds.
Wrong. I already gave an example of real code that just didn't bother to
keep track of which fd's it had open, and closed them all. Partly, in
fact, because you can't even _know_ which fd's you have open when somebody
else just execve's you.
You can call it buggy, but the fact is, if you do, you're SIMPLY WRONG.
You cannot just change years and years of coding practice, and standard
documentations. The behaviour of file descriptors is a fact. Ignoring that
fact because you don't like it is naïve and simply not realistic.
Linus
- References:
- Syslets, Threadlets, generic AIO support, v6
- Re: Syslets, Threadlets, generic AIO support, v6
- Re: Syslets, Threadlets, generic AIO support, v6
- Re: Syslets, Threadlets, generic AIO support, v6
- Re: Syslets, Threadlets, generic AIO support, v6
- Re: Syslets, Threadlets, generic AIO support, v6
- Re: Syslets, Threadlets, generic AIO support, v6
- Re: Syslets, Threadlets, generic AIO support, v6
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]