From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id ad1d3bc2 for ; Tue, 11 Feb 2020 09:16:56 +0000 (UTC) Received: (qmail 1878 invoked by uid 550); 11 Feb 2020 09:16:54 -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 1860 invoked from network); 11 Feb 2020 09:16:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell-sw-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=1IdlxApIfAKeOa4tCD32fmOj5Df9OxFAARvmsXCIFZY=; b=wnHSlUUjJi85+RDRPiua21ser+39/HFVTe5dD9jJ/lkiKjCvLydsNuSbTcZDYOD0oS VRtJO+khXQg0P6lqr2o8KGlJp2TsjZ5NfLEN5rA27xzLXqzsbLwYgyfWzH+WFThy6V5B uDepw4bvnoHfx87BxLGQlBjupZAKbx/RkAgdfZud3SHrjfnQaPf/YhgK7FiqyVxWPgPE a4pNb2nyDaWOGTptHoXOLbTdszGnbuqSoDl38DGvoGyodHjOH+AF/JlhBCDY3wZfZwtk r/sUkXMDFbiOPHpCVmJesw+hvHaUeuzFXOd1/bmtGi5vjUI7ZdbDdQEQePEdv5ewKp/T 61yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=1IdlxApIfAKeOa4tCD32fmOj5Df9OxFAARvmsXCIFZY=; b=lO/KpUwIt81tghvpQ0GTqpoJOxBq9W4H21+XZ6K93W2xpldmnG7v115bbzOGi8324y HEVC+YtmO+cmZs8GuxEyR4qrBx930APnjOAOp5Vk+hYQ0ShPwTZ1XncXoa4hgUNtshPW HQoa+LwKsspaNrWyeYmwaR7r6hGYd8M6ODP2DMFvq+E9ZF7rn1BGRYIDylP+lGeaFayX gSXQuhWrKdTQba3rJnqWuEgIUi/s0xCnOZRwxPkSJ/nnDZx7JXNlMchSqp7hdgJL+S3h ZVsYHXGwSEJQi0MLoZKkACQIIBulAnxaCXr1POjQzHTPuT+ZWnYkYJ/15HMeonfBlUy0 2ghQ== X-Gm-Message-State: APjAAAXodtStmELtaOfPjpXXM7vkxSubtTmMBFI3axWSsmrk7yec6401 gT6omCmA8LizZW1eBZRe0uoiKA== X-Google-Smtp-Source: APXvYqxAXM6xJWeWme8TkhGEKqy/Af9odQH4KfKVbaDyKDOmRsvllG0RdJjjOA9Vu85WvCjLMTYXvw== X-Received: by 2002:a2e:9744:: with SMTP id f4mr3796908ljj.267.1581412602044; Tue, 11 Feb 2020 01:16:42 -0800 (PST) To: musl@lists.openwall.com, Rich Felker References: <20200210193427.GR1663@brightrain.aerifal.cx> <14a8dbf3-1382-e61c-3b4e-3a3174dd75b2@bell-sw.com> <20200210201448.GS1663@brightrain.aerifal.cx> From: Alexander Scherbatiy Message-ID: <54047ebd-8711-1e54-e0d3-e4609cc477c7@bell-sw.com> Date: Tue, 11 Feb 2020 12:16:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200210201448.GS1663@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [musl] No such process return value in pthread_getcpuclockid On 10.02.2020 23:14, Rich Felker wrote: > The specification of ESRCH for pthread interfaces was a bug, because a > "shall fail" or even "may fail" condition makes no sense with a > behavior that's explicitly undefined (in which case the implementation > is allowed to do anything at all). This was clarified in POSIX 2008 as > a result of Austin Group interpretation 142: > > https://collaboration.opengroup.org/austin/interps/documents/14366/AI-142.txt  Thank you. It sounds right that If an application attempts to use a thread ID whose lifetime has ended, the behavior is undefined.  I see that "POSIX 2008 as a result of Austin Group interpretation 142" has strange comment about pthread_getcpuclockid() function:   "The same argument applies to the ESRCH errors for pthread_detach(),  pthread_getschedparam(), pthread_setschedparam() and  pthread_setschedprio().   (It does not apply to pthread_getcpuclockid() since the function  could just always return a fixed clock ID without needing to  examine the thread ID.)"   What does it mean that pthread_getcpuclockid() does not need to examine the thread ID? As I see from the musl pthread_getcpuclockid() implementation it really uses the thread ID: https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_getcpuclockid.c   Thanks,   Alexander. > > Unfortunately the Linux man pages have not corrected this. > > Rich