From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85FDDC43331 for ; Wed, 13 Nov 2019 06:10:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 565B3206BA for ; Wed, 13 Nov 2019 06:10:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725966AbfKMGKn (ORCPT ); Wed, 13 Nov 2019 01:10:43 -0500 Received: from albireo.enyo.de ([37.24.231.21]:46164 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725843AbfKMGKn (ORCPT ); Wed, 13 Nov 2019 01:10:43 -0500 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iUlrU-0000Rw-Vw; Wed, 13 Nov 2019 06:10:40 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1iUlrU-00074h-TE; Wed, 13 Nov 2019 07:10:40 +0100 From: Florian Weimer To: enh Cc: "Michael Kerrisk \(man-pages\)" , linux-man@vger.kernel.org Subject: Re: [PATCH] pthread_kill.3: Update to match POSIX. References: <87imnodbct.fsf@mid.deneb.enyo.de> <877e44daom.fsf@mid.deneb.enyo.de> <87woc4bv9c.fsf@mid.deneb.enyo.de> <87imnobufy.fsf@mid.deneb.enyo.de> <87r22c9ve8.fsf@mid.deneb.enyo.de> Date: Wed, 13 Nov 2019 07:10:40 +0100 In-Reply-To: (enh's message of "Tue, 12 Nov 2019 21:59:25 -0800") Message-ID: <87mud09uhr.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-man-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org * enh: > On Tue, Nov 12, 2019 at 9:51 PM Florian Weimer wrote: >> >> * enh: >> >> > no, because the C library has two choices when a thread exits: >> > >> > 1. unmap the thread. >> > >> > 2. keep the thread around for recycling. >> > >> > if you choose 1 (optimizing for space, like Android), your dereference >> > is illegal. >> >> This choice is only available for threads in a detached state. For >> joinable threads, a conforming implementation cannot immediately >> deallocate all data structures on thread termination. Among other >> things, it has to store the future return value of pthread_join >> somewhere. > > ah, you're trying to say "signal 0 is potentially usable for a > joinable thread that's waiting to be joined"? that's true, but i'm not > sure how that's relevant to this patch. that wouldn't be an "invalid > thread ID" until it's joined. Correct. That's POSIX's argument why ESRCH wouldn't be valid to return here. It's still a forceful loss of information, and particularly annoying since POSIX doesn't specify pthread_tryjoin. But I'm glad we've brought our discussion to a conclusion. 8-)