Re: [PATCH] nptl: Add pthread_thread_number_np function

[Joseph Myers <joseph at codesourcery dot com>]

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