Re: Syslets, Threadlets, generic AIO support, v6

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

Linus Torvalds a écrit :


On Wed, 30 May 2007, Davide Libenzi wrote:
Here I think we are forgetting that glibc is userspace and there's no separation between the application code and glibc code. An application linking to glibc can break glibc in thousand ways, indipendently from fds or not fds. Like complaining that glibc is broken because printf() suddendly does not work anymore ;)
No, Davide, the problem is that some applications depend on getting _specific_ file descriptors. 



Fix the application, and not adding kernel bloat ?


For example, if you do

	close(0);
	.. something else ..
	if (open("myfile", O_RDONLY) < 0)
		exit(1);

you can (and should) depend on the open returning zero.
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. 

Frankly I dont buy this fd namespace stuff.

The only hardcoded thing in Unix is 0, 1 and 2 fds.
People usually take care of these, or should use a Microsoft OS.

POSIX mandates that open() returns the lowest available fd.
But this obviously works only if you dont have another thread messing with fds, or if you dont call a library function that opens a file. 

Thats all.



So library routines *must not* open file descriptors in the normal space.

(The same is true of real applications doing the equivalent of

	for (i = 0; i < NR_OPEN; i++)
		close(i);


Quite buggy IMHO
This hack was to avoid bugs coming from ancestors applications, forking/execing a shell, and at times where one process could not open more than 20 files (AT&T Unix, 21 years ago)
Unix has fcntl(fd, F_SETFD, FD_CLOEXEC). A library should use this to make sure fd is not propagated at exec() time.
to clean up all file descriptors before doing something new. And yes, I think it was bash that used to *literally* do something like that a long time ago.
Another example of the same thing: people open file descriptors and know that they'll be "dense" in the result, and then use "select()" on them. 

poll() is nice. Even AT&T Unix had it 21 years ago :)
So it's true that file descriptors can't be used randomly by the standard libraries - they'd need to have some kind of separate "private space".
Which *could* be something as simple as saying "bit 30 in the file descriptor specifies a separate fd space" along with some flags to make open and friends return those separate fd's. That makes them useless for "select()" (which assumes a flat address space, of course), but would be useful for just about anything else. 



Please dont do that. Second class fds.

Then what about having ten different shared libraries ? Third class fds ?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[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]
  Powered by Linux