When you fork a process, the child inherits its parent's file descriptors. I understand that when this happens, the child receives a copy of the parent's file descriptor table with the pointers in each pointing to the same open file description. Is this the same thing as a file table, as in http://en.wikipedia.org/wiki/File_descriptor, or something else?
Open File Description – What is an Open File Description
file-descriptorsforkprocesses
Related Solutions
The file descriptor 1 translates to the stdout FILE structure in the Kernel's Open Files Table.
This is a misunderstanding. The kernel's file table has nothing whatsoever to do with user-space file structures.
In any event, the kernel has two levels of indirection. There is the internal structure that represents the file itself, which is reference counted. There is an "open file description" that is reference counted. And then there is the file handle, which is not reference counted. The file structure points the way to the inode itself. The open file description contains things like the open mode and file pointer.
When you call close, you always close the file handle. When a file handle is closed, the reference count on its open file description is decremented. If it goes to zero, the open file description is also released and the reference count on the file itself is decremented. Only if that goes to zero is the kernel's file structure freed.
There is no chance for one process to release a resource another process is using because shared resources are reference counted.
When a child is forked then it inherits parent's file descriptors, if child closes the file descriptor what will happen ?
It inherits a copy of the file descriptor. So closing the descriptor in the child will close it for the child, but not the parent, and vice versa.
If child starts writing what shall happen to the file at the parent's end ? Who manages these inconsistencies , kernel or user ?
It's exactly (as in, exactly literally) the same as two processes writing to the same file. The kernel schedules the processes independently, so you will likely get interleaved data in the file.
However, POSIX (to which *nix systems largely or completely conform), stipulates that read() and write() functions from the C API (which map to system calls) are "atomic with respect to each other [...] when they operate on regular files or symbolic links". The GNU C manually also provisionally promises this with regard to pipes (note the default PIPE_BUF, which is part of the proviso, is 64 kiB). This means that calls in other languages/tools, such as use of echo or cat, should be included in that contract, so if two indepenedent process try to write "hello" and "world" simultaneously to the same pipe, what will come out the other end is either "helloworld" or "worldhello", and never something like "hweolrllod".
when a process call close function to close a particular open file through file descriptor.The file table of process decrement the reference count by one.But since parent and child both are holding the same file(there refrence count is 2 and after close it reduces to 1)since it is not zero so process still continue to use file without any problem.
There are TWO processes, the parent and the child. There is no "reference count" common to both of them. They are independent. WRT what happens when one of them closes a file descriptor, see the answer to the first question.
Best Answer
file descriptor → open file description → directory entry
dupopencpThere are several levels of indirection when going from an open file in a process all the way to the file content. Implementation-wise, these levels generally translate into data structures in the kernel pointing to the next level. I'm going to describe a straightforward implementation; real implementations are likely to have a lot more complications.
An open file in a process is designated by a file descriptor, which is a small nonnegative integer. The numbers 0, 1 and 2 have conventional meanings: processes are supposed to read normal input from 0 (standard input), write normal output to 1 (standard output), and write error messages to 2 (standard error). This is only a convention: the kernel doesn't care. The kernel keeps a table of open file descriptors for each process, mapping these small integers to a file descriptor structure. In the Linux kernel, this structure is
struct fd.The file descriptor structure contains a pointer to an open file description. There can be multiple file descriptors pointing to the same open file description, from multiple processes, for example when a process has called
dupand friends, or after a process has forked. If file descriptors (even in different processes) are due to the same originalopen(or similar) system call, they share the same open file description. The open file description contains information about the way the file is open, including the mode (read-only vs read-write, append, etc.), the position in the file, etc. Under Linux, the open file description structure isstruct file.The open file description lives at the level of the file API. The next level is in the filesystem API. The distinction is that the file API covers files such as anonymous pipes and sockets that do not live in the filesystem tree. If the file is a file in the directory tree, then the open file description contains a pointer to a directory entry. There can be multiple open file descriptions pointing to the same directory entry, if the same file was
opened more than once. The directory entry contains information about what the file is, including a pointer to its parent directory, and information as to where the file is located. In the Linux kernel, the directory entry is split in two levels:struct inodewhich contains file metadata andstruct dentrywhich keep track of where the file is in the directory tree.