Re: [PATCH] nptl: Add pthread_thread_number_np function

[Rich Felker <dalias at libc dot org>]

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..

Rich