Re: [PATCH] locks: Ability to test for flock presence on fd

[Jeff Layton <jlayton@poochiereds.net>]

On Tue, 9 Sep 2014 12:18:21 -0400
"J. Bruce Fields" <bfields@fieldses.org> wrote:

> On Tue, Sep 02, 2014 at 11:07:14PM +0400, Pavel Emelyanov wrote:
> > > 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 <jlayton@poochiereds.net>