This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 2/2] manual/llio.texi: update manual to document file-private locks
- From: Michael Kerrisk <mtk dot manpages at gmail dot com>
- To: Jeff Layton <jlayton at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>, Michael Kerrisk-manpages <mtk dot manpages at googlemail dot com>
- Date: Wed, 16 Apr 2014 17:37:53 +0200
- Subject: Re: [PATCH v2 2/2] manual/llio.texi: update manual to document file-private locks
- Authentication-results: sourceware.org; auth=none
- References: <1397220945-11926-1-git-send-email-jlayton at redhat dot com> <1397220945-11926-3-git-send-email-jlayton at redhat dot com> <534888EC dot 5080309 at redhat dot com> <20140412070304 dot 014706b4 at tlielax dot poochiereds dot net> <53496F51 dot 7070009 at redhat dot com> <20140415140954 dot 773ec2f7 at tlielax dot poochiereds dot net>
Jeff, (and Carlos)
> On Sat, 12 Apr 2014 12:52:33 -0400
> "Carlos O'Donell" <carlos@redhat.com> wrote:
[...]
>> OT: Why is it F_*LKP? What does the "P" part of "LKP" mean?
That does not strike me as OT at all. The existing byte-range locking
system has persisted (despite egregious faults) for well over two
decades. One supposes that Jeff's new improved version might be around
at least as long. With that in mind, and before setting in stone (and
pushing into POSIX) a model of thinking that thousands of programmers
will live with for a long time, it's worth thinking about names.
> Sorry, forgot to answer this:
>
> "P" is for "Private". What can I say...I suck at naming things, and no
> one else proposed anything better. It's not too late to change that if
> you can come up with a better moniker, but we'd need to move fast
> before v3.15 ships.
I agree on the "suck" bit ;-). Carlos nailed it when he referred to
traditional byte-range locks as being "process-associated". That is
the distinction between these two two locking APIs: one associates
locks with the process, the other associates them with a file handle.
The terminology should reflect that difference.
>From that perspective, the word "private" here makes no sense at all.
What does "private" mean in this context? (By their very definition,
file locks are not private--they're something that is visible between
processes.) Some thought should be given to fixing that name, now, so
that we have better terminology for the coming decades ;-).
I would at the least suggest renaming these locks to something like:
file-associated locks
or
file-handle locks
or (using POSIX terminology)
file-description locks
but that last might be a bit confusing.
With some thought, you might also come up with an even better name.
But, I think *all* of the above alternatives are better than
"file-private locks".
Please consider moving to one of those pieces of terminology, or a
better one of your own creation. Note that also implies that the names
of the constants should probably change. (Already, I found the
spelling of F_SETLKPW a little strange, since I expected F_SETLKWP.)
For example, if you went with the "file handle" terminology, then
something like:
F_FH_SETLK
F_FH_SETLKW
F_FH_GETLK
That also has the advantage of making the new constants more visually
distinctive in code. (I could easily see someone accidentally omitting
the "P" in F_SETLKP, and it would not be immediately obvious at a
casual scan.)
Cheers,
Michael