[PATCH] nptl: Add pthread_thread_number_np function

[Carlos O'Donell]

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.