* CLONE_FILES description confusing
@ 2016-08-23 22:19 enh
[not found] ` <CAJgzZopmS1ph4G4zMu-_chLjsyE4CLnZiuOPqXBC=vdUE9R96w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 6+ messages in thread
From: enh @ 2016-08-23 22:19 UTC (permalink / raw)
To: Michael Kerrisk-manpages, linux-man-u79uwXL29TY76Z2rM5mHXA
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.
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 :-)
--elliott
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CLONE_FILES description confusing
[not found] ` <CAJgzZopmS1ph4G4zMu-_chLjsyE4CLnZiuOPqXBC=vdUE9R96w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-08-23 23:52 ` Michael Kerrisk (man-pages)
[not found] ` <e9dc2d61-4d72-32f4-3fb7-8864dd575f32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 6+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-08-23 23:52 UTC (permalink / raw)
To: enh, linux-man-u79uwXL29TY76Z2rM5mHXA; +Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
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)).
> 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.
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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CLONE_FILES description confusing
[not found] ` <e9dc2d61-4d72-32f4-3fb7-8864dd575f32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2016-08-24 0:11 ` enh
[not found] ` <CAJgzZor_Ru3TJfjA0L9PFo7r+2asCD+BxW=GAgmdFHY_UR2Gag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 6+ messages in thread
From: enh @ 2016-08-24 0:11 UTC (permalink / raw)
To: Michael Kerrisk (man-pages); +Cc: linux-man-u79uwXL29TY76Z2rM5mHXA
On Tue, Aug 23, 2016 at 4:52 PM, Michael Kerrisk (man-pages)
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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)).
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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CLONE_FILES description confusing
[not found] ` <CAJgzZor_Ru3TJfjA0L9PFo7r+2asCD+BxW=GAgmdFHY_UR2Gag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-08-27 11:07 ` walter harms
[not found] ` <57C17454.80707-fPG8STNUNVg@public.gmane.org>
0 siblings, 1 reply; 6+ messages in thread
From: walter harms @ 2016-08-27 11:07 UTC (permalink / raw)
To: enh; +Cc: Michael Kerrisk (man-pages), linux-man-u79uwXL29TY76Z2rM5mHXA
Am 24.08.2016 02:11, schrieb enh:
> On Tue, Aug 23, 2016 at 4:52 PM, Michael Kerrisk (man-pages)
> <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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)).
re,
wh
> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CLONE_FILES description confusing
[not found] ` <57C17454.80707-fPG8STNUNVg@public.gmane.org>
@ 2016-08-28 4:43 ` Michael Kerrisk (man-pages)
[not found] ` <63e31345-ccb2-22c8-4584-62fb32db7d96-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 6+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-08-28 4:43 UTC (permalink / raw)
To: wharms-fPG8STNUNVg, enh
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, linux-man-u79uwXL29TY76Z2rM5mHXA
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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CLONE_FILES description confusing
[not found] ` <63e31345-ccb2-22c8-4584-62fb32db7d96-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2016-09-05 18:10 ` walter harms
0 siblings, 0 replies; 6+ messages in thread
From: walter harms @ 2016-09-05 18:10 UTC (permalink / raw)
To: Michael Kerrisk (man-pages); +Cc: linux-man-u79uwXL29TY76Z2rM5mHXA
Am 28.08.2016 06:43, schrieb Michael Kerrisk (man-pages):
> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> Hello Elliott
>>>>
>>
>>
>> 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
>
>
Most people are bad at negations. The patch attempts to reword the
description of the CLONE_FILES without describing "what is not does
when not set".
This changes not the whole file but it should give an idea how it could be done.
re,
wh
----
diff --git a/man2/clone.2 b/man2/clone.2
index b867961..fd25e38 100644
--- a/man2/clone.2
+++ b/man2/clone.2
@@ -172,6 +172,17 @@ Store the child thread ID at the location
in the child's memory.
.TP
.BR CLONE_FILES " (since Linux 2.0)"
+
+By default the child process still inherits a copy of all file descriptors
+opened in the calling process at the time of
+.BR clone ().
+The child and parent process can close or change
+file descriptors independently.
+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
+.BR open (2)).
+
If
.B CLONE_FILES
is set, the calling process and the child process share the same file
@@ -187,20 +198,6 @@ If a process sharing a file descriptor table calls
.BR execve (2),
its file descriptor table is duplicated (unshared).
-If
-.B CLONE_FILES
-is not set, the child process inherits a copy of all file descriptors
-opened in the calling process at the time of
-.BR 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
-.BR open (2)).
.TP
.BR CLONE_FS " (since Linux 2.0)"
If
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-09-05 18:10 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-23 22:19 CLONE_FILES description confusing enh
[not found] ` <CAJgzZopmS1ph4G4zMu-_chLjsyE4CLnZiuOPqXBC=vdUE9R96w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-08-23 23:52 ` Michael Kerrisk (man-pages)
[not found] ` <e9dc2d61-4d72-32f4-3fb7-8864dd575f32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-08-24 0:11 ` enh
[not found] ` <CAJgzZor_Ru3TJfjA0L9PFo7r+2asCD+BxW=GAgmdFHY_UR2Gag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-08-27 11:07 ` walter harms
[not found] ` <57C17454.80707-fPG8STNUNVg@public.gmane.org>
2016-08-28 4:43 ` Michael Kerrisk (man-pages)
[not found] ` <63e31345-ccb2-22c8-4584-62fb32db7d96-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-09-05 18:10 ` walter harms
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.