Re: Syslets, Threadlets, generic AIO support, v6

From: Eric Dumazet
Date: Wed May 30 2007 - 17:57:31 EST


Linus Torvalds a écrit :

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.

If someone really cares, /proc/self/fd can help. But one shouldn't care at all.

About the things that the process can do before execing() a process, file descriptors outside of 0,1,2 are the most obvious thing, but you also have alarm(), or stupid rlimits.


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.

I want to change nothing. Current situation is fine and well documented, thank you.

If a program does "for (i = 0; i < NR_OPEN; i++) close(i);", this *will*/*should* work as intended : close all files descriptors from 0 to NR_OPEN. Big deal.

But you wont find in a program :

FILE *fp = fopen("somefile", "r");
for (i = 0; i < NR_OPEN; i++)
close(i);
while (fgets(buff, sizeof(buff), fp)) {
}


You and/or others want to add fd namespaces and other hacks.

I saw on this thread suspicious examples, I am waiting for a real one, justifying all this stuff.

After file descriptors separation, I guess we'll need memory space separation as well, signal separations (SIGALRM comes to mind), uid/gid separation, cpu time separation, and so on... setrlimit() layered for every shared lib.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/