|
Message-ID: <54047ebd-8711-1e54-e0d3-e4609cc477c7@bell-sw.com> Date: Tue, 11 Feb 2020 12:16:18 +0300 From: Alexander Scherbatiy <alexander.scherbatiy@...l-sw.com> To: musl@...ts.openwall.com, Rich Felker <dalias@...c.org> Subject: Re: 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
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.