Re: flock(2): locking against itself?

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

    Date:        Sun, 19 Mar 2023 07:05:52 +0000
    From:        David Holland <dholland-tech%netbsd.org@localhost>
    Message-ID:  <ZBa0UBAPjDAhGOBF%netbsd.org@localhost>

  | "They're per-open"

That's not bad for this level of description.

  | ...which is not actually difficult to understand since it's the same
  | as the seek pointer behavior; that is, seek pointers are per-open too.

and almost all the other transient attributes, that is distinct
from stable attributes like owner, group, permissions, which are
inode attributes.  In our current system I think just close on exec
is a per fd (transient) attribute though if we follow linux (I think)
and soon to be POSIX, and add close on fork, that would be another.

But this doesn't help with initial understanding, there is nothing
fundamental that requires things to be this way, both seek pointers,
and locks, could be per fd, or per inode (transitory, or long term).
They just aren't.   (There is no need to explain why, I know why,
but newcomers, not that mouse is one, don't necessarily).

Then to add to all of that we have fcntl locks, with their process
lifetime nonsense integrated, making a mess of the model, they're
basically per-open, but with that (kind of) per fd complication added
on top.

kre