This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] nptl: Add pthread_thread_number_np function
- From: Florian Weimer <fweimer at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Fri, 9 Mar 2018 18:23:51 +0100
- Subject: Re: [PATCH] nptl: Add pthread_thread_number_np function
- Authentication-results: sourceware.org; auth=none
- References: <20171214185611.D08E1439942EA@oldenburg.str.redhat.com> <email@example.com> <firstname.lastname@example.org> <20180302180416.GB1436@brightrain.aerifal.cx> <20180302180850.GC1436@brightrain.aerifal.cx>
On 03/02/2018 07:08 PM, Rich Felker wrote:
Further, making it lazy also improves the latter aspect if you're
unwilling to make a dedicated "failure" value. "Libc has to abort if
you ever create more than 2^64 threads" is an awful constraint to be
tied to. "Libc aborts if you ever call this random nonstandard
function from more than 2^64 unique threads" seems tolerable since the
simple mitigation is "don't use that function".
Currently glibc policy is to assume that 2**60 counters never overflow
(without any checks). We have functionality which underwent extensive
peer review with this property.
However, I will come up with something else since there appears to be a
strong dislike for this interface.