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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,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 8358 invoked from network); 31 Mar 2020 17:21:35 -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:21:35 -0000 Received: (qmail 20089 invoked by uid 550); 31 Mar 2020 17:21:33 -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 20068 invoked from network); 31 Mar 2020 17:21:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1585675281; bh=hjzSGiuDctVXp5RvL6CkKfgCZ3dhDR4bLvNLISdXjU8=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=MyJM2Jah2mOTdUD9t5bY98+XRs0kSySQYhiXbW5YbFHqwAr2tNoGMnvVnAqe3CIiS s8ob3dXkXlMrkVubL2WM9u0fk3RqC45zP7e7gqMAu6itTVrUlkCQ5S7relc4mQ9bhX eEQ/C0s9XwS29cOcyYOv+6tiJpkfjVsFTTZ2iGF0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Tue, 31 Mar 2020 19:21:20 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20200331172120.GA2683@voyager> References: <5a0db239-4121-8a70-832a-e43ce7632d8e@ncentric.com> <20200331150912.GU11469@brightrain.aerifal.cx> <20200331152646.GV11469@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200331152646.GV11469@brightrain.aerifal.cx> User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:h8GvMmiEDnTxemlOGJGipufibAPnWdE6ZqS64KBgazqQ/rew0kx KjHCyCAef3Gq6vkRYf5A/KCE7wHG/rhB8c/Lo4jisZkJvkTrz6lGtt0/VHjJH0yZuPu3Pw7 WoWTCU2IY3sxQ/5liUGAsVZ4KkoTNx9I4/jGLPeVvIsCsUFQjsYM64J/wfIX0bKz6eBLSNG +ExEyabLMT3zGfnFRBr/A== X-UI-Out-Filterresults: notjunk:1;V03:K0:+RFxCuw9zXU=:kFt2DQ4wpD8v6ZYyuOIJd8 6aCi0mn6DNknxHqPjluViz/natI52q//AJTED6GRSKC+UV7JNVNtKNpKYEJ8sYb2QmmZE2Rh4 1aplRSCIl+q+h0etldWvQwxwUBBuYh7Qo3zgv9A4hsSwmI+8LYlYtGKU+bUc6xHKzTBPxWpaF 75dP/hzxfu+49oc9bZ5qJ/8GEu1EdkxOAhR7hCzDR+5fG6U+XzguVDlXt0dNXWWR6NJOk9FGb ooRG13pK5fIIiY3cdF6tHtU8vgGljz1iHQOCWBqTX4GmIYcnfNjRjsxQ8+kW1kVot22YPPy2h Q77KAgNXumqwmFirXXjgen/blsCLMaE8NcXTdWiOxNxcs9JIoTeo8QKD4blxUQGCTyGHB74U8 LpWS+ick6CkseZD2gdhz11CFOSjTzhx7U7J+iK0Hsk5ErQUD4jg2S3LrSHx3z3lkafvlBXI+N YZ5jIs/YIqbW518O0k3iF0yKB67vYLhNbeJ9+0syYOJZ/OYoAueHmpfGeJe4rdc5IjEGCzX+W aNTeTqjfYnaTFoElYZvuoKjPDiEXW25IRvu4Zdnxj2VEqmJFy7EVE4unzP2QQtVn1eKLA6eLR 8a4TpeF455g3HTedAiIiq9feug2DNBZdWv1wCJDZ0mGmX+yJkMZy4Y44ik38zMGyf1TtAbe6l K+5MMehWPHpvmCbQ3m9Mmuw/t2g8HagWxO1xt/x5XnmFGQuxH0GeWU7UXEG5iW1V7jHrNvNMg F02jGeFwlN/8KE5KTKoBGHka58uQhj4s+2/xL3u5vhC5zrmpp203lSHjNOrofNK+2OlAthoAI 3P6g0cJrI0SMlIe/XfzjZYlh4FTRiXK+3URbv0rqnKwlz7OAEH/dh9CSjfjw2Aw/oHUFHfB72 Lew/9HSoWCbxR7yCDVuERbqy4ynmrNSyrcuUglT3Ret0KhjkqIYKGKnw+1iZ2FmFL804gV1Ob wrFhQNhXpkhla3fHnex4eiRAMNLDOltYbxkyM1eWvPM27sKcBfEZDt+84mLnCuM+A0epHS7qS 8lQZ1pxU7Gw310QtJBln0M3QQiSnwG2iibsL+B2/Z1gQvNuUwYeRRuA7myN0Pda1xVceLXfDO fLZh7lHdX2UaUsrbhd9qJV68CnxxQoMFvLst9CrjaFTXLk8ux6GPzfJcJLx52GSg/x932sZj3 2GENfNTZDbvX9cvvTBCkD2rWUZyg7Mfpjc/IjPO0sCcfq5qP6pSnWTlna+pzZ1o8gtfL5zuBx S2J44LUqZMmn9Mmju Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Simple question regarding read-write locks precedence 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. Ciao, Markus