Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 31 Mar 2020 13:37:24 -0400
From: Rich Felker <>
Cc: "Michael Kerrisk (man-pages)" <>
Subject: Re: Simple question regarding read-write locks precedence

On Tue, Mar 31, 2020 at 07:21:20PM +0200, Markus Wichmann wrote:
> On Tue, Mar 31, 2020 at 11:26:46AM -0400, Rich Felker wrote:
> > Thanks. While I specifically did not implement (or define a macro for)
> > PTHREAD_RWLOCK_PREFER_WRITER_NP because it's misleading to advertise
> > support for it when it fundamentally can't work,
> > extension to support. Anyone else see potential problems supporting it
> > that I might be missing?
> >
> > Rich
> I do see one problem: The manpage (the only spec available) contradicts
> itself. In the Description section, it says (of the new option):
> |Setting the lock kind to this avoids writer starvation as long as any
> |read locking is not done in a recursive fashion.
> OK, but in the Bugs section:
> |allows writers to run, but, as the name implies a writer may not lock
> |recursively.
> Well, which is it? Are writers or readers not supposed to recurse? I
> thought writers aren't supposed to recurse, anyway. Or is it possible we
> need to file a bug report to Michael Kerrisk? Maybe it was supposed to
> say "reader" here, then it would make sense. As it stands, though, the
> spec is unclear.

I think that's pretty clearly just a mistake in the man page that
should be reported. CC'ing.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.