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

[Jonathan Wakely]

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?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 24667 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20201112/fc752486/attachment-0001.bin>