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>
Attachment:
signature.asc
Description: Digital signature
