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
> 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
> 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
sorry if my words was not clear last time
MHD.Tayseer
