C++ std::async and std::future support

[adamfowleruk]

I have a C++ library which I'm porting to work on Zephyr. This uses the Zephyr Bluetooth API. I have successfully linked the library during its development and have most functionality working. For ease I'd like to use std::async and std::future in my code for my library. If I do this, I cannot currently port it to Zephyr. (Compile error below). I note the previous catch-all issues #18554 #31281.

Describe the solution you'd like
I would like support for std::async and std::future please. (I realise this implies other C++17 functionality needs implementing too)

Describe alternatives you've considered
Adding my own template primitives when std library support isn't available - but this of course leads to complexity in the library.

Additional context
I'm more than happy to assist in writing and testing this as it would be ideal for a COVID-19 project I'm working on ( https://github.com/vmware/herald-for-cpp ). I have several Nordic DK boards for testing.

herald-for-cpp/herald/src/engine/coordinator.cpp:152:23: error: variable 'std::future<void> fut' has initializer but incomplete type
[build]      std::future<void> fut = std::async(std::launch::async,
[build]                        ^~~
[build] D:/git/skunkworks/herald-for-cpp/herald/src/engine/coordinator.cpp:159:6: error: invalid use of incomplete type 'class std::future<void>'
[build]      });
[build]       ^
[build] In file included from D:/git/skunkworks/herald-for-cpp/herald/src/engine/coordinator.cpp:16:
[build] c:\gnuarmemb\arm-none-eabi\include\c++\8.3.1\future:125:11: note: declaration of 'class std::future<void>'
[build]      class future;

[baw-serafin]

std::async will dynmically create (std?)Threads which is not something that will easy to do as there is no support for std::threads so far as I understand.

[carlescufi]

@adamfowleruk I had a look at your Herald project, that is really interesting, thanks for sharing with us.
Regarding the support for these C++ features, I don't think there is anything preventing Zephyr from supporting them other than someone willing to take the time and actually write the code. If you are looking for collaborators to help you in this effort I suggest that you email one of our mailing lists and link to this issue there.

Also, @pabigot might have additional insights aside from what was already mentioned by @baw-serafin.

[pabigot]

Not really. Zephyr was never designed with C++ in mind, and advanced features like threads and atomics might be difficult to backfill. It is a significant amount of work, especially if we need to support multiple toolchains.

[zephyrbot]

Hi @stephanosio,

This issue, marked as an Enhancement, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

@adamfowleruk you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.

Thanks!