On 16/11/20 14:43 -0800, Thomas Rodgers wrote:
This patch looks good to me.
Committed now.
It would be great to find a way to do a similar refactoring of
condition_variable.
Yes, probably once stage 1 opens for GCC 12.
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>
