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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
