{"id":108375,"date":"2023-06-27T07:00:00","date_gmt":"2023-06-27T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=108375"},"modified":"2023-06-19T06:25:13","modified_gmt":"2023-06-19T13:25:13","slug":"20230627-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20230627-00\/?p=108375","title":{"rendered":"How to wait for multiple C++ coroutines to complete before propagating failure, unhelpful lambda"},"content":{"rendered":"

Last time, we found a solution for waiting for multiple C++ coroutines to complete before propagating failure<\/a>, but it relied on expansion statements<\/i>, which weren’t finished in time for C++20. We’ll have to find something that uses only features available in C++20, or even better, works in C++17.\u00b9<\/p>\n

The usual way to get expansion-like behavior is to use a lambda and the comma operator:<\/p>\n

([&](auto& arg) {\r\n    \/* do something *\/\r\n}(args), ...);\r\n<\/pre>\n
So let’s try applying it to our “wait for all” coroutine function:<\/p>\n
template<typename... T>\r\nIAsyncAction when_all_complete(T... asyncs)\r\n{\r\n    std::exception_ptr eptr;\r\n\r\n    ([&] (auto& async) {\r\n        try {\r\n            co_await async;\r\n        } catch (...) {\r\n            if (!eptr) {\r\n                eptr = std::current_exception();\r\n            }\r\n        }\r\n    }(asyncs), ...);\r\n\r\n    if (eptr) std::rethrow_exception(eptr);\r\n}\r\n<\/pre>\n
Sadly, this doesn’t work because the lambda performs a co_await<\/code>, and co_await<\/code> requires that you be in a coroutine.<\/p>\n
I guess we have to make the lambda a coroutine.<\/p>\n
template<typename... T>\r\nIAsyncAction when_all_complete(T... asyncs)\r\n{\r\n    std::exception_ptr eptr;\r\n\r\n    auto each = [&] (auto& async) -> IAsyncAction {\r\n        try {\r\n            co_await async;\r\n        } catch (...) {\r\n            if (!eptr) {\r\n                eptr = std::current_exception();\r\n            }\r\n        }\r\n    };\r\n\r\n    (co_await each(asyncs), ...);\r\n\r\n    if (eptr) std::rethrow_exception(eptr);\r\n}\r\n<\/pre>\n
One thing you might object to is the fact that we have a lambda coroutine with a capture. This is generally frowned upon, due to the risk of the lambda being destructed while suspended, but it works here because the lambda is not destructed until when_all_complete<\/code> finishes executing all of its co_await<\/code>s. Even if one of the calls to co_await async<\/code> throws an exception, that exception is caught and saved in eptr<\/code>, and the overall coroutine completes without an exception.<\/p>\n
It looks like we’ve done it, but there’s a catch: The threading model.<\/p>\n
In the original when_all<\/code>, the parameters were each co_await<\/code>ed directly in the main function, which means that if any of the co_await<\/code>ed things changed threads, the thread change would remain in effect for the next co_await<\/code>:<\/p>\n
winrt::fire_and_forget example()\r\n{\r\n    co_await winrt::when_all(resume_background(), Something());\r\n}\r\n<\/pre>\n
Inside when_all<\/code>, this expands into<\/p>\n
auto first = resume_background();\r\nauto second = Something();\r\nco_await first;\r\nco_await second;\r\n<\/pre>\n
The co_await first<\/code> performs a thread switch, and the co_await second<\/code> executes on the new thread.<\/p>\n
This is different from our when_all_complete<\/code> because that one wraps each co_await<\/code> inside another IAsyncAction<\/code>, which changes the threading behavior: In C++\/WinRT, co_await<\/code>ing an IAsyncAction<\/code> resumes on the same apartment that started the co_await<\/code>. Since we wrapped each awaitable inside a lambda that produces an IAsyncAction<\/code>, each co_await<\/code> of the lambda will resume back on the original apartment, even if the original awaitable completed in a different apartment.<\/p>\n
Here’s a comparison: With expansion statements, we just co_await<\/code> directly from the function.<\/p>\n
IAsyncAction v1(async1, async2)\r\n{\r\n    co_await async1;\r\n    co_await async2;\r\n}\r\n<\/pre>\n
Suppose that async1<\/code> completes on a different apartment. (For example, it might be an apartment-switching awaitable, like resume_background<\/code>.) Then the co_await async1<\/code> will complete on the other apartment, and the co_await async2<\/code> therefore begins on that other apartment.<\/p>\n
On the other hand, with a lambda, we co_await<\/code> from a lambda, and then co_await<\/code> the lambda.<\/p>\n
IAsyncAction v2(async1, async2)\r\n{\r\n    co_await [](auto& async) -> IAsyncAction {\r\n        co_await async;\r\n    }(async1);\r\n\r\n    co_await [](auto& async) -> IAsyncAction {\r\n        co_await async;\r\n    }(async2);\r\n}\r\n<\/pre>\n
First, we invoke the lambda, which does a co_await async1<\/code>, which completes on some other apartment. However, since we co_await<\/code> the lambda, and the lambda itself returns an IAsyncAction<\/code>, the co_await<\/code> of the lambda will complete back on the original<\/i> apartment (because that’s how the IAsyncAction<\/code> awaiter works). Next, we co_await async2<\/code>, which now begins on the original apartment, not the apartment in which async1<\/code> completed.<\/p>\n
Next time, we’ll try to get all the co_await<\/code>s to happen in the main function, so that we can preserve the apartment-switching behavior of the original when_all<\/code> function.<\/p>\n
Spoiler alert: Next time will be a failure.<\/p>\n
\u00b9 Yes, coroutines are not part of C++ until C++20, but the Microsoft Visual Studio compiler lets you opt into coroutine support while in C++17 mode, so “C++17 with optional coroutines” is the current baseline for C++\/WinRT.<\/p>\n","protected":false},"excerpt":{"rendered":"
The usual trick doesn’t work.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-108375","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
The usual trick doesn’t work.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108375","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=108375"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108375\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=108375"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=108375"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=108375"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}