This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC][glibc PATCH] fcntl-linux.h: add new definitions and manual updates for open file description locks
- From: Jeff Layton <jlayton at redhat dot com>
- To: ams at gnu dot org
- Cc: libc-alpha at sourceware dot org, linux-fsdevel at vger dot kernel dot org, linux-kernel at vger dot kernel dot org, tytso at mit dot edu, dalias at libc dot org, mtk dot manpages at gmail dot com, samba-technical at lists dot samba dot org, nfs-ganesha-devel at lists dot sourceforge dot net, carlos at redhat dot com, metze at samba dot org, hch at infradead dot org, bharrosh at panasas dot com
- Date: Wed, 23 Apr 2014 15:23:18 -0400
- Subject: Re: [RFC][glibc PATCH] fcntl-linux.h: add new definitions and manual updates for open file description locks
- Authentication-results: sourceware.org; auth=none
- References: <1398253172-9221-1-git-send-email-jlayton at redhat dot com> <E1Wcyo3-0000Eg-UC at fencepost dot gnu dot org> <20140423112843 dot 77889d16 at tlielax dot poochiereds dot net> <E1Wd2Os-00061e-GU at fencepost dot gnu dot org>
On Wed, 23 Apr 2014 15:00:06 -0400
ams@gnu.org (Alfred M. Szmidt) wrote:
> > Likewise. You infact write that it does get the lock information
> > later in the document wrt. F_OFD_GETLK.
>
> Sorry, I disagree here...GETLK is really a misnomer, IMO. TESTLK
> would have been a better name.
>
> GETLK are used is to "get the first lock".
>
> It's a way to test whether a particular lock can be applied, and to
> return information about a conflicting lock if it can't. If, for
> instance there is no conflicting lock, then you don't "get" any
> lock information back (l_type just gets reset to F_UNLCK).
>
> While I kinda see your point, it isn't what GETLK does; it really does
> get you information about the first lock -- you're not testing
> anything. It is also the terminology used in the POSIX standard.
You *are* testing a lock.
For instance, a process has locked bytes 0-5 for read in the file. I
then submit a F_GETLK request from another process and set:
l_type = F_WRLCK
l_start = 7
l_len = 1
...this range does not overlap with the original range, and so no lock
will be returned even though one is being held on the file. In order to
determine whether it should return information about a lock it has to
first _test_ whether it conflicts with the information in the struct
flock that was passed down.
Similarly, if the struct flock I submit to the F_GETLK request has this:
l_type = F_RDLCK
l_start = 0
l_len = 1
...then I also will not get any information about a lock back. The
information in the lock request does not conflict with the one being
held on the file (because they are both read locks).
If F_GETLK were just "getting" a lock, then there would be no test
involved, but that's not how this works. F_GETLK has to test and see
whether there is a conflicting lock before it can return anything.
If all you're objecting to is the change in verbiage on those two
pieces, then I'll back that part out in the interest of wrapping this
up.
I still think I'm correct though ;)
--
Jeff Layton <jlayton@redhat.com>