This is the mail archive of the libc-alpha@sourceware.org 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 12/22/2017 08:24 AM, Florian Weimer wrote:
> On 12/21/2017 08:19 PM, Carlos O'Donell wrote:
>> On 12/21/2017 03:03 AM, Florian Weimer wrote:
>>> On 12/21/2017 10:26 AM, Carlos O'Donell wrote:
>>>
>>>>> +The returned number is only unique with regards to the current process.
>>>>> +It may be shared by subprocesses and other processes in the system.
>>>>> +
>>>>> +The initial (main) thread has number 1.  Thread numbers are not
>>>>> +necessarily assigned in a consecutive fashion.  They bear no
>>>>> +relationship to POSIX thread IDs (@code{pthread_t} values), process IDs
>>>>> +or thread IDs assigned by the kernel.
>>>>
>>>> I would like us to add something like this:
>>>> ~~~
>>>> While the return type of this function is only 64-bits wide, the intent
>>>> is not to impose an artificial limit on the number of threads that can be
>>>> created by the runtime. In the future this interface may be extended
>>>> to 128-bits to support creating as many threads as a user may need
>>>> for the lifetime of the process.
>>>> ~~~
>>>>
>>>> That way the intent of the interface and future changes are clear.
>>>
>>> So how would a programmer use this interface in a future-proof way?
>>> I think such a statement would raise more questions than it answers.
>>
>> I went to bed thinking much the same thing and worried that perhaps this
>> text was not appropriate for the manual, but could serve as a comment in
>> the source code for future maintainers. Since this is really a question
>> about GNU ethos and avoiding artificial limits.
>>
>> Would you be opposed to adding the comment to the new function sources?
> 
> What about this?
> 
> /* 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.

>>>> People start relying on this counter incrementing from 1 upwards.
>>>>
>>>> People start using this monotonic property for indexing.
>>>>
>>>> Soon we can't change it because it's implied API behaviour.
>>>>
>>>> I think we should disabuse them from doing something low cost to roll the value:
>>>>
>>>> * Do nothing for thread 1, leaving it 1.
>>>> * Check global_thread_number for overflow instead.
>>>> * Pick a random number of bits to roll between 0-63 (picked at process startup)
>>>> * Roll the value by some that number of bits.
>>>> * Use the rolled value as the thread_number
>>>
>>> Not sure if I understand this.  Do you want us to start at a random
>>> value?  Or assign IDs randomly?  The latter will have a collision
>>> much sooner.
>>>
>>> I can switch the thread numbers to a fixed, but random-looking
>>> permutation of the integers in [0, 2**64), but this looks excessive.
>>
>> I want a low cost solution that avoids abuses of the interface for
>> indexing into arrays, or other issues that would break when we change
>> this in the future. We do not want users to make assumptions about the
>> values we hand out.
> 
> But the result will be that the numbers are no longer short and
> easily compared for logging/debugging purposes.  I think the value of
> that is higher than trying to punish developers who do not read the
> manual.

The numbers are meaningless and should be handled by computers, and
compared by log analyzers, just like how PIDs today are meaningless
and not that small. Even PIDs in logs are large enough that I can't
easily remember them, though I agree that 34519 vs. 431234789734231
is really a big difference.

My objection remains that I think we should have some kind of
perturbation logic in the number generation, but my objection is
*not* sustained.

I do not block consensus, perturbation can continue to be discussed
and applied at a later point. Therefore between you and I there is
consensus that this patch looks good for addition as a new POSIX
thread API.

Please place your patches on the "Release blockers" for this release:
https://sourceware.org/glibc/wiki/Release/2.27#Release_blockers.3F,
so we get them checked in fully.

I say this because I want someone else other than me to ACK these
before we consider the new API OK. I'm hesitant to pursue a model
where we add new APIs without at least two senior reivewer's
consent. I would like Siddhesh to just look over the idea, and give
a +1 to the new API, knowing that I have reviewed the technical
details I want a high-level acceptance of the direction the API
is going. Siddhesh was the last to add a new POSIX thread API with
the default thread attribute settings API being his invention.

Siddhesh, Could you review the high-level details of the new API?

-- 
Cheers,
Carlos.


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