Hi, > 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. but if, after fork, one of them (either the child or the father) closes the file, how will it still stay available to the second one ? > > > 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*. you mean the same logic that explained above about the file descriptors table, goes to the signal handlers table too ? thanks G. -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
