From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 10421 invoked from network); 31 Mar 2020 17:37:39 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 31 Mar 2020 17:37:39 -0000 Received: (qmail 26321 invoked by uid 550); 31 Mar 2020 17:37:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26297 invoked from network); 31 Mar 2020 17:37:36 -0000 Date: Tue, 31 Mar 2020 13:37:24 -0400 From: Rich Felker To: musl@lists.openwall.com Cc: "Michael Kerrisk (man-pages)" Message-ID: <20200331173724.GW11469@brightrain.aerifal.cx> References: <5a0db239-4121-8a70-832a-e43ce7632d8e@ncentric.com> <20200331150912.GU11469@brightrain.aerifal.cx> <20200331152646.GV11469@brightrain.aerifal.cx> <20200331172120.GA2683@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200331172120.GA2683@voyager> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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, > > PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP seems like a viable > > 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: > > |Setting the lock kind to PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP > |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. Rich