CODEWITHSUNDEEP
clinuxunix
ultimate cause
ultimate cause

Reputation: 2294

Why only the lowest available file descriptor is allocated in UNIX?

In a group talk I was intrigued by this question -

Why UNIX standard demands the guarantee of allocation of only lowest available file descriptor for a process ?

And only possible answer that I could thought of was scalability. Since we always choose the least available descriptor, the used portion of the descriptor bitmap is mostly dense and thus the growth of array is slower.

I was just wondering if there are any other reasons which I am not aware of.

Also, do we have some scenarios where logical conclusions (those we can use in a program) can be made if we know that a given descriptor is bigger/smaller than the other. My understanding though does NOT allows using such technique because it does NOT guarantee the age of the descriptor.

Upvotes: 3

Views: 2735

Answers (3)

Aaron Digulla
Aaron Digulla

Reputation: 328614

Simple: In 1970, 64 KB (65536 bytes) were a lot. That's the kind of system on which Unix was invented (a PDP-7 to be exact which came with 9 KB by default with an option to upgrade it to 144 KB ... for, say, $20'000).

In that kind of environment, every single bit is valuable (which explains some of the weird stuff that confuse the spoiled brats today like using integers to save pointers and vice versa).

So the algorithm would try to allocate the first free file descriptor in a very small table (which was fixed in size at the time). This would also make the algorithm terminate faster which was also good since most computers could only execute a few 10-100 thousand commands per second.

Upvotes: 0

rici
rici

Reputation: 241771

If you close standard input (fd 0) and then open a new file, it will get fd 0. (Similarly for fds 1 and 2, stdout and stderr, if the lower fds have not been closed.) That predictability is useful and was used in many unix programs before dup2 was standardized in order to redirect standard input/output/error in a child process.

Upvotes: 3

Jonathan Leffler
Jonathan Leffler

Reputation: 754020

There are various reasons, but the ultimate one is "because that's the way it has always been done".

  1. It is easy to track through the list of file descriptors to find the first unused one.
  2. It is determinate. This was important before the dup2() call was available.

Classically, the file descriptor table for a process was a fixed size, and quite small (20 in 7th Edition Unix, IIRC).

The deterministic mechanism was crucial for I/O redirection in shell. For example:

cat file1 file2 > file3

The shell needed to redirect standard output to file3. Therefore, it could use:

close(1);  // Standard output
if (open("file3", O_WRONLY|O_CREAT, 0666) != 1)
   …error creating file…

and it would know that because standard input was already open (file descriptor 0), the open() would return file descriptor 1.

These days, you can't deduce anything much from a file descriptor value. I can write:

int fd1 = open(filename, flags, mode);
int fd2 = dup2(fd1, 1024);
close(fd1);

and the fact that fd2 (should) contain 1024 doesn't tell you anything about the order in which it was opened compared to file descriptor 3 (which might plausibly be returned by the next open() call).

Upvotes: 6

Related Questions