StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>In the same section, of book, there is a diagram showing three tables which are there when a file is opened.</p> <p>The user filedescriptor table(part of the process table entry), filetable and inode table (v-node table). Now a filedescriptor (which is an index to the file descriptor table) entry points to a file table entry,which points to a inode table entry.<br> Now the <strong>file offset</strong> (the position from where the next read/write happens) is there in the <strong>File table.</strong></p> <p>So say you have a file opened in parent, that means it is having a descriptor, a file table entry and an inode reference too.<br> Now when you are creating a child the file descriptor table is copied for the child. So the reference count in the file table entry (for that open descriptor) is increased that means now there are two references for the same file table entry.</p> <p><strong>This descriptor is now available in both parent and child, pointing to the same File Table entry, hence sharing the offset.</strong> Now having this background let us see your questions, </p> <ol> <li>What does it mean? if parent's std output is redirected to a 'file1' for example, then what should child update after child writes? parent's original std output offset or redirected ouput(i.e file1) offset? Can't be the later, right?]</li> </ol> <p>The child explicitly need not update anything. The author of the book is trying to<br> tell that, suppose parents's standard out put is redirected to a file and the a fork call is made. After that the parent is wating.So the descriptor is now duplicated, that is the file offset is also shared. Now whenever now the child writes anything to standard out, the written data is saved in the redirected file. <strong>The offset automatically is incremented by the write call.</strong></p> <p>Now say the child exits. So the parent come out of waiting and writes something on the standard out(which is redirected). Now where the parent 's write call's output will be placed -> after the data, which was written by the child. Why -> since the offset's current value is now changed after the child has written.</p> <pre><code> Parent ( ) { open a file for writing, that is get the descriptor( say fd); close(1);//Closing stdout dup(fd); //Now writing to stdout means writing to the file close(fd) //Create a child that is do a fork call. ret = fork(); if ( 0 == ret ) { write(1, "Child", strlen("Child"); exit .. } wait(); //Parent waits till child exit. write(1, "Parent", strlen("Parent"); exit .. } </code></pre> <p>Pl. see the above pseudo code, the final data that the opened file contains will be ChildParent. So you see that the file offset got changed when the child has written and this was avilable to the parent's write call, since the offest is shared.</p> <p>2.How is the update done? by child explicitly, by OS implicitly, by files descriptor itself? After fork, i thought parent and child went their own ways and has their own COPY of file descriptor. So how does child update offset to parent side?]</p> <pre><code>Now I think the answer is clear-> by the system call that is by the OS. </code></pre> <p>[3. When fork() is invoked, all i understand is that child get a COPY of what parent has, file descriptor in this case, and does its thing. If any offset changes to file descriptor that parent and child share, it can only be because the descriptor remember the offset itself. Am i right?]</p> <p>This should also be clear. The entry of the user file table points to the file table table entry (which contains the offset).</p> <p>In other words, the system calls can fetch the offset from the descriptor.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload