Re: libpthread removal project

[Florian Weimer <fweimer at redhat dot com>]

* Siddhesh Poyarekar:

>> Some libraries (including libstdc++) use weak symbol references to
>> detect the presence of libpthread.  If libpthread has not been loaded,
>> they assume that they do not have to use atomics for updating counters
>> etc.  After libpthread removal, this optimization no longer works.  This
>> is why I plan to add the __libc_single_threaded variable as a
>> replacement, which will continue to work for detecting single-threaded
>> processes once pthread_create or pthread_key_create are always
>> available.  (The not-linking-against-libpthread optimization is already
>> of decreased use today because a lot of single-threaded processes load
>> the library indirectly, so I think .)
>
> Does it make sense to add a pthread_num_threads_np or similar as a
> supported API for users?  While not-linking-against-libpthread is
> decreasing in utility, avoiding locks when single-threaded may actually
> be widely useful.

This is what __libc_single_threaded is about.  It's a variable, not a
function, to avoid the function call overhead.

As far as thread counts go, only the value 1 is special.  A general
thread count does not seem useful to me because it's not stable (for any
value above 1), and libraries do not know what the count means.  For
example, half of the threads could be parked on some rarely-occurring
condition, so for pretty much all practical purposes, they do not count.

Thanks,
Florian