[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: flock(2): locking against itself?
Date: Sat, 18 Mar 2023 19:46:17 -0400 (EDT)
From: Mouse <mouse%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
| 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.
Main Index |
Thread Index |