Re: [PATCH] libstdc++: Enable <thread> without gthreads

[Thomas Rodgers <rodgert@appliantology.com>]

This patch looks good to me.

It would be great to find a way to do a similar refactoring of condition_variable.

> On Nov 12, 2020, at 9:07 AM, Jonathan Wakely via Libstdc++ <libstdc++@gcc.gnu.org> wrote:
> 
> On 11/11/20 17:31 +0000, Jonathan Wakely wrote:
>> On 11/11/20 16:13 +0000, Jonathan Wakely wrote:
>>> This makes it possible to use std::thread in single-threaded builds.
>>> All member functions are available, but attempting to create a new
>>> thread will throw an exception.
>>> 
>>> The main benefit for most targets is that other headers such as <future>
>>> do not need to include the whole of <thread> just to be able to create a
>>> std::thread. That avoids including <stop_token> and std::jthread where
>>> not required.
>> 
>> I forgot to mention that this patch also reduces the size of the
>> <thread> header, by only including <bits/unique_ptr.h> instead of the
>> whole of <memory>. That could be done separately from the rest of the
>> changes here.
>> 
>> It would be possible to split std::thread and this_thread::get_id()
>> into a new header without also making them work without gthreads.
>> 
>> That would still reduce the size of the <future> header, because it
>> wouldn't need the whole of <thread>. But it wouldn't get rid of
>> preprocessor checks for _GLIBCXX_HAS_GTHREADS in <stop_token>.
>> 
>> Allowing std::this_thread::get_id() and std::this_thread::yield() to
>> work without threads seems worth doing (we already make
>> std::this_thread::sleep_until and std::this_thread::sleep_for work
>> without threads).
> 
> Here's a slightly more conservative version of the patch. This moves
> std::thread and this_thread::get_id() and this_thread::yield() to a
> new header, and makes *most* of std::thread defined without gthreads
> (because we need the nested thread::id type to be returned from
> this_thread::get_id()). But it doesn't declare the std::thread
> constructor that creates new threads.
> 
> That means std::thread is present, but you can't even try to create
> new threads. This means we don't need to export the std::thread
> symbols from libstdc++.so for a target where they are unusable and
> just throw an exception.
> 
> This still has the main benefits of making <future> include a lot less
> code, and removing some #if conditions in <stop_token>.
> 
> One other change from the previous patch worth mentioning is that I've
> made <bits/std_thread.h> include <bits/refwrap.h> so that
> std::reference_wrapper (and std::ref and std::cref) are defined by
> <thread>. That isn't required, but it is a tiny header and being able
> to use std::ref to pass lvalues to new threads without including
> all of <functional> seems like a kindness to users.
> 
> Both this and the previous patch require some GDB changes, because GDB
> currently assumes that if std::thread is declared in <thread> that it
> is usable and multiple threads are supported. That's no longer true,
> because we would declare a useless std::thread after this patch. Tom
> Tromey has patches to make GDB handle this though.
> 
> Tested powerpc64le-linux, --enable-threads and --disable-threads.
> 
> Thoughts?
> 
> 
> <patch.txt>