On Sun, Dec 25, 2005 at 12:58:43 +0200, MHD.Tayseer Alquoatli wrote: > On 12/25/05, Rajaram Suryanarayanan <rajaram_linux@xxxxxxxxx> wrote: > > Here CLONE_FILES is not passed. i.e open file objects are not shared with > > the new process (child)...? But I have studied that when a process forks a > > child process, the files open by the parent will be shared with the new > > child process. And the reference count will also be incremented by 1. There are two things. The file handle used in userspace, which is an integeral index into a file descriptor table, and the file descriptor itself, which is struct file. The struct file is *always* shared after both clone and fork. The CLONE_FILES flag specifies whether the file descriptor *table* will be shared, or not. > > Can anybody pls explain this..? > > well .. when you call fork, the process descriptor of the calling process > will be duplicated, then the new copy will be given to the child process > control. > you can see that if a process has already opened 4 files there will be 7 > files in the process file table (stdin, stdout, stderr, 4files then the new > duplicated copy generated by fork will have the same entries in it's file > table .. but from this moment and on .. each process (the parent and the > child) will work on it's own copy .. and after this point, if the parent > process opened a file nothing will be affected in the child process > descriptor, and vice verse This is not true, actually. They do share the struct file and since that is where the current position lives, the current position WILL be affected. That's why if parent and child both have a log file open (from before fork) and write to it, output from BOTH will be there, mixed together. > here you can find the difference between clone and fork .. when a process > clones a thread using clone then the new process descriptor (actually it's > called "task" in Linux) will point it's resources like the file table to the > parent process .. it won't copy it, it'll point to it instead .. and this is > the reason why the process and the cloned task will still be able to share > opened files (and any other cloned resource) till the end No. fork, though being a different syscall, is a strict subset of clone. sys_clone (_syscall2(int, clone, int, flags, void *, child_stack)) with flags of 0 and child stack of NULL does exactly fork. Note, that it is flags 0, *NOT* CLONE_SIGHAND. Again CLONE_SIGHAND does not mean the installed handlers remain the same -- the *always* do -- but that the descriptor table is shared -- which after fork it is *NOT*. -- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
