Date: Sat, 18 Mar 2023 19:46:17 -0400 (EDT) From: Mouse <mo...@rodents-montreal.org> Message-ID: <202303182346.taa01...@stone.rodents-montreal.org>
| Except they aren't. They're on open file table entries, something | remarkably difficult to describe in a way that doesn't just refer to | the kernel-internal mechanism behind it Yes. The terminology in this area really sucks, but that's why I mentioned 'kernel file*' in my message. POSIX distinguishes file descriptors and file descriptions, but you have to be reading very carefully to even notice the difference - ok for a standards doc perhaps, not for a man page or e-mail message. Given the lack of well understood terminology, it is not easy to do better. That, I assume, is what led to that paragraph in the NOTES section - an attempt to explain better just where the locks fit, without getting into kernel internals (the access model the kernel provides, that is, fd, file*, vnode, data, really needs to be understood in order to do any non-trivial file related operations). | If they were truly on files, rather than open file | table entries, then it wouldn't matter whether my test program opened | the file once or twice, since it's the same file either way. There you're thinking of vnode (or since it is a file, perhaps more accurately, inode) operations. The only operations possible on the actual file are read/write/truncate. The terminology sucks. It has done for 50 years now, and in that time nothing better has ever caught on, so hoping for something tomorrow is probably forlorn. | Hm, okay, I can see how the second flock call in my test was taken as | an attempt to equalgrade aka no-op. Yes. kre