On Tue, Sep 02, 2014 at 11:07:14PM +0400, Pavel Emelyanov wrote:
quoted
Would it make sense to return the lock type held instead, so you could
do one flock(fd, LOCK_TEST) instead of flock(fd, LOCK_TEST|LOCK_SH) and
flock(fd, LOCK_TEST|LOCK_EX) ?
Well, in our case we parse /proc/locks anyway to see what
files at least to test for being locked. But what you propose
looks even better. I'll look what can be done here.
Actually I think I prefer your version. It seems cleaner to define
LOCK_TEST as returning the same result as you'd get if you actually
tried the lock, just without applying the lock. It avoids having a
different return-value convention for this one command. It might avoid
some ambiguity in cases where the flock might be denied for reasons
other than a conflicting flock (e.g. on NFS where flocks and fcntl locks
conflict). It's closer to what GETLK does in the fcntl case.
--b.
On Tue, 9 Sep 2014 12:18:21 -0400
"J. Bruce Fields" [off-list ref] wrote:
On Tue, Sep 02, 2014 at 11:07:14PM +0400, Pavel Emelyanov wrote:
quoted
quoted
Would it make sense to return the lock type held instead, so you could
do one flock(fd, LOCK_TEST) instead of flock(fd, LOCK_TEST|LOCK_SH) and
flock(fd, LOCK_TEST|LOCK_EX) ?
Well, in our case we parse /proc/locks anyway to see what
files at least to test for being locked. But what you propose
looks even better. I'll look what can be done here.
Actually I think I prefer your version. It seems cleaner to define
LOCK_TEST as returning the same result as you'd get if you actually
tried the lock, just without applying the lock. It avoids having a
different return-value convention for this one command. It might avoid
some ambiguity in cases where the flock might be denied for reasons
other than a conflicting flock (e.g. on NFS where flocks and fcntl locks
conflict). It's closer to what GETLK does in the fcntl case.
Yeah, I think I agree here too. Best to keep the interface as simple
as possible, and the principle of least surprise would dictate that the
return value match how other flock() calls work.
I would still like to see a proposed manpage update for it. For bonus
points, writing a section on flock() for the glibc manual might help
get that piece merged as well.
It was my experience that getting the small header file #defines into
glibc for OFD locks was much more difficult than the kernel piece. YMMV
of course, but getting the glibc folks to buy into the idea ahead of
time would be good if possible.
--
Jeff Layton [off-list ref]