[PATCH] nptl: Add pthread_thread_number_np function

Florian Weimer fweimer@redhat.com
Fri Dec 22 19:39:00 GMT 2017


On 12/22/2017 06:43 PM, Joseph Myers wrote:
> 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.

Yes, I considered using a different type, but it really has to be a 
fixed type anyway so that the format specifiers work.  That's why I went 
with uint64_t in the end.

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

In the attached patch, I added <bits/pthread-common.h> to simplify this. 
  I verified that it is installed as 
$(DESTDIR)/usr/include/bits/pthread-common.h.

Thanks,
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thread-number-common.patch
Type: text/x-patch
Size: 37547 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20171222/350927be/attachment.bin>


More information about the Libc-alpha mailing list