[PATCH] nptl: Add pthread_thread_number_np function

[Joseph Myers]

On Fri, 22 Dec 2017, Carlos O'Donell wrote:

> > /* This function should ideally return an integer wider than uint64_t,
> >    so that the thread number can never-ever overflow.  We may have to
> > Â Â  switch to a 128-bit return value for new architectures
> > Â Â  (particularly if those provide atomic operations on 128-bit
> >    integers).  But with current architectures, the baked-in limit of
> > Â Â  2**64 threads ever created by a process is not a problem because
> > Â Â  architectural constraints result in a thread creation rate far
> > Â Â  below one billion threads per second, and even at that rate, a
> >    64-bit counter lasts for hundreds of years.  */
> 
> This looks good to me. Thanks.

I wonder about representing the intent to allow for a larger type by 
defining and documenting the API to use a pthread_thread_number_t type 
rather than uint64_t.

However, if pthread_thread_number_t is to be conveniently usable, it 
should be specified to be an unsigned integer type, meaning no wider than 
uintmax_t (so you can cast to uintmax_t to print with %ju, for example), 
meaning it can't be unsigned __int128 for any existing glibc ABI as all 
such ABIs have 64-bit uintmax_t.

As with any patch changing the installed pthread.h, the separate hppa 
version of that header needs the same change applied.

-- 
Joseph S. Myers
joseph@codesourcery.com