On 08/27/2016 11:07 PM, walter harms wrote: > > > Am 24.08.2016 02:11, schrieb enh: >> On Tue, Aug 23, 2016 at 4:52 PM, Michael Kerrisk (man-pages) >> <mtk.manpages@xxxxxxxxx> wrote: >>> Hello Elliott >>> >>> On 08/24/2016 10:19 AM, enh wrote: >>>> CLONE_FILES (since Linux 2.0) >>>> If CLONE_FILES is set, the calling process and the child process >>>> share the same file descriptor table. Any file descriptor cre‐ >>>> ated by the calling process or by the child process is also >>>> valid in the other process. Similarly, if one of the processes >>>> closes a file descriptor, or changes its associated flags (using >>>> the fcntl(2) F_SETFD operation), the other process is also >>>> affected. >>>> >>>> this is fine. >>>> >>>> If CLONE_FILES is not set, the child process inherits a copy of >>>> all file descriptors opened in the calling process at the time >>>> of clone(). (The duplicated file descriptors in the child refer >>>> to the same open file descriptions (see open(2)) as the corre‐ >>>> sponding file descriptors in the calling process.) Subsequent >>>> operations that open or close file descriptors, or change file >>>> descriptor flags, performed by either the calling process or the >>>> child process do not affect the other process. >>>> >>>> this is strictly correct, but (having just had to explain what this >>>> descriptor/description distinction actually means in practice here) i >>>> think it would be helpful to explicitly mention that changes to the >>>> file offset or file status flags in one process *does* affect the >>>> other process. >>> >>> Yes, it wouldn't hurt to be a bit more explicit. I made the second paragraph: >>> >>> If CLONE_FILES is not set, the child process inherits a >>> copy of all file descriptors opened in the calling process >>> at the time of clone(). Subsequent operations that open or >>> close file descriptors, or change file descriptor flags, >>> performed by either the calling process or the child >>> process do not affect the other process. Note, however, >>> that the duplicated file descriptors in the child refer to >>> the same open file descriptions as the corresponding file >>> descriptors in the calling process, and thus share file >>> offsets and files status flags (see open(2)). >> > > > Just one note: > People are terrible bad at negation. So i would suggest: > > If CLONE_FILES is set, the child process share > all file descriptors opened in the calling process > at the time of clone(). > Subsequent operations that open or close file descriptors, > or change file descriptor flags, performed by either > the calling process or the child > process do also affect the other process. > Note, however, > that the duplicated file descriptors in the child refer to > the same open file descriptions as the corresponding file > descriptors in the calling process, and thus share file > offsets and files status flags (see open(2)). Hi Walter, I am having trouble to see what you find wrong, and what you want to change, since the text comparison is difficult. Could you formulate this as a patch? Thanks, Michael >> lgtm. thanks! >> >>>> less important, but another suggestion would be that maybe we should >>>> also explicitly say that "clone calls for thread creation pass >>>> CLONE_FILES, but fork(3) calls clone without CLONE_FILES" so that >>>> folks who know how to use the C library but not how it's implemented >>>> don't need to ask their friendly local C library implementer (me) >>>> exactly how CLONE_FILES works :-) >>> >>> There is a small hint about this in the fork(2) man page. I'm not >>> (yet) convinced more is really needed. >> >> all i meant was "most folks already correctly understand the >> fd-related implications of pthread_create and fork, so pointing out >> the parallel would have made the distinction between CLONE_FILES and >> no CLONE_FILES more obvious to them". but i think the new text is fine >> anyway. >> >>> Thanks for the report. >>> >>> Cheers, >>> >>> Michael >>> >>> -- >>> Michael Kerrisk >>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ >>> Linux/UNIX System Programming Training: http://man7.org/training/ >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-man" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
