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 (man-pages)" <mtk dot manpages at gmail dot com>
- To: Jeff Layton <jlayton at redhat dot com>
- Cc: mtk dot lists at gmail dot com, libc-alpha at sourceware dot org
- Date: Wed, 16 Apr 2014 17:09:55 +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> <534E8209 dot 3070705 at gmail dot com> <20140416094827 dot 0b5ad446 at tlielax dot poochiereds dot net>
- Reply-to: mtk dot manpages at gmail dot com
Hi Jeff,
On Wed, Apr 16, 2014 at 3:48 PM, Jeff Layton <jlayton@redhat.com> wrote:
> On Wed, 16 Apr 2014 15:13:45 +0200
> "Michael Kerrisk (man-pages)" <mtk.lists@gmail.com> wrote:
>
>> On 04/11/2014 02:55 PM, Jeff Layton wrote:
>> > Signed-off-by: Jeff Layton <jlayton@redhat.com>
>>
>> [...]
>>
>
> You may want to look at the v3 patch I sent yesterday. It has some
> changes, but I think your comments below still apply to it.
Ahhh -- I missed that. (Please CC mtk.manpages@mail.com on v4.) Still,
I tried to take case that I did not duplicate any of the points that
Carlos made, so I guess most of what I said was relevantËseems so from
your feedback).
>> > controlling access to a file. There is still potential for access to
>> > the file by programs that don't use the lock protocol.
>> >
>> > +@node File-private Locks
>> > +@section File-private Locks
>> > +
>> > +In contrast to classic record locks (@pxref{File Locks}), file-private
>> > +locks are associated with an open file table entry rather than a
>> > +process. File-private locks set on an open file descriptor will never
>>
>> s/File-private locks/New file-private locks/
>>
>
> Carlos suggested avoiding adjectives like "new" or "classic" because in
> a year or two, these will no longer be "new". I've moved to using
> "process-associated" instead of "classic" in the latest rev and
> dropping the "new" moniker.
I think you've missed my point. Here, "new" is not about the "new type
of file lock" its about placing a "new" lock on a a file that has an
"existing" lock. Perhaps "new" is still not quite right though.
Perhaps something like:
[[
Using @code{fcntl} to apply a file-private lock on a region that
already has an existing file-private lock that was created via the
same open file descriptor will never cause a lock conflict...
]]
I have some comments on the naming that of this locking system that
I'll put elsewhere into this thread.
> Thanks for the review.
You're welcome. Thanks for doing the documentation. As Carlos pointed
out, it's a little exceptional that that happens.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/