> On May 24, 2020, at 11:11 AM, Jonathan Wakely <jwakely....@gmail.com> wrote:
>
> On Sun, 24 May 2020 at 18:55, Florian Weimer wrote:
>>
>> * Thomas Rodgers:
>>
>>> + static __gthread_t
>>> + _S_get_tid() noexcept
>>> + {
>>> +#ifdef __GLIBC__
>>> + // For the GNU C library pthread_self() is usable without linking to
>>> + // libpthread.so but returns 0, so we cannot use it in single-threaded
>>> + // programs, because this_thread::get_id() != thread::id{} must be
>>> true.
>>> + // We know that pthread_t is an integral type in the GNU C library.
>>> + if (!__gthread_active_p())
>>> + return 1;
>>> +#endif
>>> + return __gthread_self();
>>> + }
>>
>> This comment seems outdated or incomplete. pthread_self returns a
>> proper pointer since glibc 2.27, I believe.
>
> The comment is copied from the <thread> header, and dates from 2015.
Yes, this comes from <thread> to avoid pulling in all of <thread> to just get a
hash from the current thread identity. I’m now using it in two places, is this
worth splitting out somewhere?
>
>> I'm also not sure how the difference is observable for the libstdc++
>> implementation. Late loading of libpthread isn't quite supported.
>
> It's nothing to do with late loading. A single threaded program that
> doesn't create any threads and doesn't link to libpthread can still
> expect std::this_thread::get_id() != std::thread::id() to be true in
> the main (and only) thread. If pthread_self() returns 0, and
> thread::id() default constructs with a value of 0, then we can't
> distinguish "the main thread" from "not a thread".
>
> But I do see a non-zero value from glibc now, which is great. I'll add
> it to my TODO list to remove that workaround from <thread>.
