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++ > <libstd...@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>
