Re: flock(2): locking against itself?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 18 Mar 2023 19:46:17 -0400 (EDT)
    From:        Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <202303182346.TAA01658%Stone.Rodents-Montreal.ORG@localhost>

  | 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