This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] nptl: Add pthread_thread_number_np function
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