Hi all, By reading all these mails on fork( clone ) its very difficult for me ( and i think all the students those r very new to linux kernel and os development ) to learn what is actually happening after fork, i.e open files are shared r not. so can any body plz explain it clearlly. Thanks in advance Deepak Joshi. --- Jan Hudec <bulb@xxxxxx> wrote: > On Sun, Dec 25, 2005 at 16:12:13 +0200, MHD.Tayseer > Alquoatli wrote: > > > 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. > > > > we are talking about the opened file table that is > in the task descriptor > > Sure we are. But the original poster was not at all > clear what he was talking > about. > > > > > > > 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. > > > > this is right .. the struct file (which is part of > the VFS structs for every > > file system) will be shared .. but this is only > -as i've pointed out- when > > the file has been opened before calling fork .. i > think i was clear that > > what i meant is the file descriptor table which > will be duplicated .. after > > calling fork you cannot open a file from the > parent task, then pass the new > > file descriptor index to the child task some how > and then let the child task > > calls "read" from that file descriptor index cause > it's not associated with > > the new task's files descriptor table > > Sure. But you started with 'the process descriptor > will be duplicated', which > is not very clear. The 'process descriptor' is > struct task_struct. Well, that > will always be duplicated. The important point is > that clone duplicates the > *table* of file descriptors, not the file > descriptors (struct file) > themselves as the original poster seemed to think. > > > > > 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*. > > > > > > when you ask "clone" not to clone anything it'll > do as fork does (i.e. will > > duplicate the task descriptor) but if you ask > "clone" to clone resources A > > and B for example it'll duplicate the task > descriptor and then let resource > > A and B from the child task point to resource A > and B from the parent task > > without allocating anything for them > > -- > Jan 'Bulb' Hudec <bulb@xxxxxx> > ___________________________________________________________ Yahoo! Photos ? NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
