This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: libpthread removal project
- From: Siddhesh Poyarekar <siddhesh at gotplt dot org>
- To: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 7 Oct 2019 13:18:33 -0400
- Subject: Re: libpthread removal project
- References: <87eezsj0jb.fsf@oldenburg2.str.redhat.com>
On 04/10/19 5:57 am, Florian Weimer wrote:
> One of my long-term goals is to remove libpthread and move everything
> into libc. The remaining library will just be stub, and maybe contain
> some compatibility data symbols (if we have any by then).
Finally!
> 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.
Siddhesh