Re: [PATCH] nptl: Add pthread_thread_number_np function

[Rich Felker <dalias at libc dot org>]

On Fri, Mar 02, 2018 at 01:04:16PM -0500, Rich Felker wrote:
> On Fri, Dec 15, 2017 at 08:47:54AM +0100, Florian Weimer wrote:
> > >We could allocate the thread numbers lazily, and that would certainly
> > >avoid limiting ourselves to only allocating 2^64-1 threads. On top of
> > >that if the function could return an error then we could return such
> > >an error at overflow:
> > >
> > >  int pthread_thread_number_np (uint64_t* thread_number, pthread_t @var{thread})
> > >
> > >Returns 0 if the thread has a unique number, otherwise -1 if it does not.
> > 
> > That's a bad interface.  If you are worried about 64-bit overflow,
> > we should use a 128-bit counter instead, but I'm not convinced this
> > is necessary.
> > 
> > Lazy allocation would make the function not safe for use in signal handlers.
> 
> This is trivially false. You just have to block and restore signal
> mask around taking and releasing the lock to make it AS-safe.
> 
> I'm also rather unhappy with an API whose external interface is an
> assumption that you can never create more than 2^64 threads, even
> though from a practical standpoint is seems impossible for the
> forseeable future. Just documenting a special return value
> (UINT64_MAX? 0?) that means the result was not meaningful would be a
> decent fix, given that this whole interface is of dubious utility..

Further, making it lazy also improves the latter aspect if you're
unwilling to make a dedicated "failure" value. "Libc has to abort if
you ever create more than 2^64 threads" is an awful constraint to be
tied to. "Libc aborts if you ever call this random nonstandard
function from more than 2^64 unique threads" seems tolerable since the
simple mitigation is "don't use that function".

Rich