This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] nptl: Add pthread_thread_number_np function
On 03/09/2018 11:23 AM, Florian Weimer wrote:
> 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.
They were internal hidden API details though?
Like pthread cond signal groups, and fork counters.
> However, I will come up with something else since there appears to be
> a strong dislike for this interface.
Either lazy allocation, or a dedicated overflow value are both useful
improvements to a "thread identification" API that has inherent limits
on the size of the identification name space (64-bits).
I don't object because we have lots of space-limited objects like inodes,
etc, and all we've done is make new APIs with wider width types to
resolve these problems.
Cheers,
Carlos.