CLONE_FILES description confusing

[enh <enh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>]

       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