This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]