Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Say I have process 1 and process 2. Both have a file descriptor corresponding to the integer 4.

In each process however the file descriptor 4 points to a totally different file in the Open File Table of the kernel:

enter image description here

How is that possible? Isn't a file descriptor supposed to be the index to a record in the Open File Table?

share|improve this question
    
Good question! My guess is that the file descriptors are translated, so that the fd 4 in both processes are relative to it's own number of open fd's. Fd's 0-2 (stdin,stdout,sdterr) are always opened for a new process and the numbers are not reserved for only that process. –  Herman Torjussen Jan 5 '12 at 16:04
1  
related question? –  jw013 Jan 5 '12 at 16:07
    
@jw013 I thought this sounded familiar. \@Pithikos How is this not a duplicate? –  Michael Mrozek Jan 5 '12 at 16:23
    
@Michael Mrozek This is indeed a duplicate. However I reedited the question as I didn't get any good explanation on the old one. (This scheme is also much more relevant to the question.) –  Pithikos Jan 5 '12 at 16:33
1  
This is a poor diagram - it should show that file descriptor 4 means the fourth entry [well, fifth, it's counted from zero] of the file descriptor table on the left, not an entry which contains a "4". The actual "4" lives in your userspace variable containing the number. The diagram in the other question is much better. –  Random832 Jan 5 '12 at 18:21

4 Answers 4

up vote 14 down vote accepted

The file descriptor, i.e. the 4 in your example, is the index into the process-specific file descriptor table, not the open file table. The file descriptor entry itself contains an index to an entry in the kernel's global open file table, as well as file descriptor flags.

share|improve this answer
2  
For the record, there is only one "file descriptor flag" on most systems, the close-on-exec flag. All other "per-fd" state (including the offset and the access mode) is part of the open file table entry. –  Random832 Jan 5 '12 at 18:45

Each process has its own file descriptor table. File descriptor 4 in process 1234 points inside process 1234's table. File descriptor 4 in process 5678 points inside process 5678's table. A case you must be familiar with are file descriptors 0, 1 and 2 which for each process are the standard input, standard output and standard error, pointing wherever these were redirected to.

A process can open the same file more than once. This can happen coincidentally, for example when a process's standard output and standard error are redirected to the same terminal or to the same file. The underlying file table entries (e.g. Linux's struct file) carry more than information about the file; they also contain opening modes (e.g. read or write) and other state (such as flags, e.g. close-on-exec). For example, a process might have a terminal opened for reading only on file descriptor 0 and that same terminal opened for writing only on file descriptor 2. File tables entries also contain the process's position in the file; a process might want to lseek to two different positions in the same file, and so would use dup to obtain two handles to that file.

share|improve this answer
1  
This isn't entirely correct. According to the man page / specs, dup does an exactly what it says on the tin: both resulting descriptors point to the same file table entry and thus share the same offset. In order to get 2 different file table entries, I'm pretty sure you need to open the file twice. –  jw013 Dec 17 '11 at 1:32
    
@Gilles "File descriptor 4 in process 1234 points inside process 1234's table". Which table do you mean? From what I know the only table in the process is the File Descriptor Table where each record points to the kernel's single Open File Table. –  Pithikos Jan 5 '12 at 15:35

Wouldn't an extra level of indirection fix your problem? ("All problems in computer programming can be solved by an extra level of indirection" - some wise greybeard). That is, the small integer in each process ends up as an index into a per-process array of kernel-space indexes into the "Open File Table".

share|improve this answer
    
The source wise greybeard is likely David Wheeler. It appears he also said, "But that usually will create another problem." :) –  jw013 Jan 5 '12 at 16:12

Each process has it's own file descriptor table. That's all.

It's all very well described in UNIX Network Programming by Richard Stevens if you would like to learn it deeply.

share|improve this answer
    
Which table are you referring to? –  Pithikos Jan 5 '12 at 22:13
1  
file descriptor table –  Michał Šrajer Jan 5 '12 at 23:49

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.