This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2 2/2] manual/llio.texi: update manual to document file-private locks


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]