On Tue, May 31, 2016 at 08:44:34PM +0200, Stef Bon wrote: > > IOW, they can do readdir in parallel exactly in the cases when lseek > > done by one of them would not affect another. > > And when lseek does not affect another? Is this right: When there are > no changes in the entries, no entries are created or removed > (or moved away)?? > (which probably means the cache of names in the directory is uptodate). No. On any Unix, since before the transition to PDP-11, there is a distinction between file descriptor and opened file. There are three layers of objects in there: 1) descriptor 2) opened file 3) filesystem object Each has its own set of properties and system calls to manipulate those. open(2) creates new objects in layers 1 and 2. dup(2) acts in layer 1 alone - you get a new descriptor refering to the same opened file (unfortunate name, that - something like "open IO channel" would be less confusing). fork(2) also acts only on layer 1. The primary effect of close(2) is also in layer 1, but the side effects might reach into layers 2. lseek(2) is a layer 2 operation. Current IO position is a property of an opened file, *not* of a descriptor or of underlying filesystem object. Had been, since the moment they'd implemented redirects. For a TTY it doesn't matter, but think what happens when you do (date; ls) > foo. shell opens the file we are redirecting to and uses dup2() (or close() + dup(), for that matter) to make descriptor 1 (stdout) point to it. Then date(1) writes a string to its descriptor 1 (inherited from shell). Then ls(1) does the same. Both pieces of output end up written to foo; so far, so good, but you want the output of ls(1) start *after* the output of date(1). In other words, current IO position should be shared across fork() and dup(). OTOH, it obviously can't be a property of underlying filesystem object - you do _not_ want e.g. grep qsort *.[ch] from one terminal to play havoc on cc a.c from another. Each time you call open(2) you get a new opened file (IO channel, whatever you call it) *and* a new descriptor refering to it. fork()/dup()/dup2()/close() act upon descriptors; so does exit(), for that matter. When all references to an opened file disappear, that opened file gets closed. It is a common effect of close(2), but it's a separate event; moreover, that event might have further side effects - if a file had been opened and unlinked, closing the opened file in question might trigger the destruction of underlying filesystem object, provided there's no surviving hardlinks to it. read()/write()/lseek() act upon the opened file; it is specified by descriptor, but the effects are the same whichever descriptor refering to that opened file had been used. On the other had, the effect *does* depend upon the opened file being involved, not just the underlying filesystem object. All of the above applies to directories. Well, almost - you get getdents(2) instead of read(2) and no analogue of write(2). The notion of the current IO position, desciptor vs. opened file distinction, difference between open() + dup() and open() + open() - all of that is identical to the situation with regular files. "struct file" is a fairly common name for the structure representing an opened file (regardless of the file type). On all kind of Unices, Linux included... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
