{"id":108405,"date":"2023-07-10T07:00:00","date_gmt":"2023-07-10T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=108405"},"modified":"2023-06-19T07:48:17","modified_gmt":"2023-06-19T14:48:17","slug":"20230710-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20230710-00\/?p=108405","title":{"rendered":"How to wait for multiple C++ coroutines to complete before propagating failure, concluding remarks"},"content":{"rendered":"

For the past several articles, we’ve looked at how we could write a when_all_completed<\/code> function that awaits a set of awaitable objects, and only after all of them have been awaited does it propagate any exception that occurred. A lot of our work was erasing sources of exceptions that could occur before<\/i> all of the awaitables have completed, most notable “out of memory” exceptions in the internal bookkeeping. We eventually were able to get rid of all the dynamic memory allocations in the coroutine body.<\/p>\n

So we’re done, right?<\/p>\n

Well, no, because things could go wrong before we get to the coroutine body.<\/p>\n

Consider this usage:<\/p>\n

co_await when_all_completed(First(), Second(), Third());\r\n<\/pre>\n
This breaks down into multiple steps:<\/p>\n
auto first = First();\r\nauto second = Second();\r\nauto third = Third();\r\nauto action = when_all_completed(first, second, third);\r\nco_await action;\r\n<\/pre>\n
(I’ve removed some std::move()<\/code> calls for expository simplicity.)<\/p>\n
All of our work to get rid of exceptions in the body of when_all_completed<\/code> ensure that the co_await action<\/code> throws an exception only because one of the awaitable parameters threw an exception, and not because we encountered a std::bad_alloc<\/code> trying to do our work.<\/p>\n
However, there are all the other steps that lead to the co_await<\/code> that could still go wrong.<\/p>\n
For example, if we make it past the calls of First()<\/code> and Second()<\/code>, but the call to Third()<\/code> throws an exception, then the exception will propagate out of the full expression, and the First()<\/code> and Second()<\/code> coroutines will be left running without having ever been awaited.<\/p>\n
So it’s not good enough to say<\/p>\n
try {\r\n    co_await when_all_completed(First(), Second(), Third());\r\n} catch (...) {\r\n    \/* Ignore errors, but at least we know that all of\r\n     * the coroutines have completed, right? *\/\r\n}\r\n<\/pre>\n
\"Anakin\/Padme<\/p>\n
If an exception occurs while producing the coroutines, then that exception is thrown, and when_all_completed<\/code> is never even called. Any coroutines which started prior to the exception are still running.\u00b9<\/p>\n
There’s also the possibility of a std::bad_alloc<\/code> thrown by the failed allocation of the coroutine frame. We were able to eliminate this in our custom promise by preallocating space and using a secret signal to pass this preallocated space to the promise’s operator new<\/code>. However, we want when_all_completed<\/code> to return a C++\/WinRT IAsyncAction<\/code>, and we don’t control the operator new<\/code> of the associated promise; that one came from C++\/WinRT.<\/p>\n
The best we can do is to catch the exception from the creation of the IAsyncAction<\/code> and fail fast.<\/p>\n
template<typename... T>\r\nIAsyncAction when_all_complete_worker(T... asyncs)\r\n{\r\n    std::exception_ptr eptr;\r\n\r\n    auto accumulate = [&](std::exception_ptr e) {\r\n        if (eptr == nullptr) eptr = e;\r\n    };\r\n\r\n    (accumulate(co_await wrapped_awaitable(asyncs)), ...);\r\n\r\n    if (eptr) std::rethrow_exception(eptr);\r\n}\r\n\r\ntemplate<typename... T>\r\nIAsyncAction when_all_completed(T&&... async) noexcept\r\n{\r\n    return when_all_complete_worker(\r\n        std::forward<T>(async)...);\r\n}\r\n\r\nfire_and_forget SomeFunction()\r\n{\r\n    auto first = First();\r\n    auto second = Second();\r\n    auto third = Third();\r\n    try {\r\n        co_await when_all_completed(\r\n            std::move(first),\r\n            std::move(second),\r\n            std::move(third));\r\n    } catch (...) {\r\n        LOG_CAUGHT_EXCEPTION();\r\n    }\r\n}\r\n<\/pre>\n
We move the coroutine into a helper function when_all_complete_worker()<\/code> and and the new when_all_complete()<\/code> function just forwards the parameters to the worker, but does so in a noexcept<\/code> function, so if there is a problem allocating the coroutine frame or copying the parameters into the coroutine frame, the exception triggers a std::terminate<\/code>.<\/p>\n
Note that we called First()<\/code>, Second()<\/code>, and Third()<\/code> outside of the try<\/code>. This means that if (say) Third()<\/code> throws an exception without producing an awaitable, the exception propagates immediately, and the coroutines First()<\/code> and Second()<\/code> are never awaited to completion.<\/p>\n
That’s probably not what you want, since the point of running them to completion is to make sure they have stopped doing work before allowing the next thing to happen.<\/p>\n
So the calls to create the three coroutines should probably be inside a noexcept<\/code>.<\/p>\n
\/\/ Go back to the old when_all_completed\r\n\r\nfire_and_forget SomeFunction()\r\n{\r\n    try {\r\n        co_await [&amp]() noexcept {\r\n            return when_all_completed(\r\n                First(),\r\n                Second(),\r\n                Third());\r\n        }();\r\n    } catch (...) {\r\n        LOG_CAUGHT_EXCEPTION();\r\n    }\r\n}\r\n<\/pre>\n
This is still awkward enough that it’s unlikely anybody would write it.<\/p>\n
How about changing when_all_completed<\/code> so it returns the exception instead of rethrowing it?<\/p>\n
template<typename... T>\r\ncom_aware_task<\/a><std::exception_ptr><\/span>\r\nwhen_all_complete(T... asyncs)\r\n{\r\n    std::exception_ptr eptr;\r\n\r\n    auto accumulate = [&](std::exception_ptr e) {\r\n        if (eptr == nullptr) eptr = e;\r\n    };\r\n\r\n    (accumulate(co_await wrapped_awaitable(asyncs)), ...);\r\n\r\n    co_return eptr;<\/span>\r\n}\r\n\r\nfire_and_forget SomeFunction()\r\n{\r\n    auto eptr = co_await when_all_completed(\r\n            First(), Second(), Third());\r\n    if (eptr) {\r\n        try {\r\n            std::rethrow_exception(eptr);\r\n        } catch (...) {\r\n            LOG_CAUGHT_EXCEPTION();\r\n        }\r\n    }\r\n}\r\n<\/pre>\n
This time, we allow any exceptions from First()<\/code>, Second()<\/code>, Third()<\/code>, or when_all_completed<\/code> itself to propagate outward, which in the case of a winrt::fire_and_forget<\/code> means immediate termination. If any of the awaitables complete with an exception, we log the exception (by rethrowing it and immediately catching it with a logging function). If this is pattern you intend to use a lot, you could wrap it in a helper.<\/p>\n
void LogExceptionPtr(std::exception_ptr eptr)\r\n{\r\n    if (eptr) try {\r\n        std::rethrow_exception(eptr);\r\n    } CATCH_LOG();\r\n}\r\n\r\nfire_and_forget SomeFunction()\r\n{\r\n    LogExceptionPtr(co_await when_all_completed(\r\n            First(), Second(), Third()));\r\n}\r\n<\/pre>\n
But if you’re going to be logging and discarding exceptions, maybe you want to just make when_all_completed<\/code> do it. After all, there could be multiple exceptions, and when_all_completed<\/code> returns only the first one.<\/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 accumulate = [&](std::exception_ptr e) {\r\n        if (e) {                          <\/span>\r\n            LogExceptionPtr(e);           <\/span>\r\n            if (eptr == nullptr) eptr = e;<\/span>\r\n        }                                 <\/span>\r\n    };\r\n\r\n    (accumulate(co_await wrapped_awaitable(asyncs)), ...);\r\n\r\n    if (eptr) std::rethrow_exception(eptr);\r\n}\r\n<\/pre>\n
That said, you may want to make Log\u00adException\u00adPtr<\/code> a macro, so that the error log will have a line number that points to the LOG_EXCEPTION_PTR<\/code> rather than to the helper function.<\/p>\n
#define LOG_EXCEPTION_PTR(eptr) \\\r\ndo { if (auto&& __eptr = eptr) \\\r\n    try { std::rethrow_exception(__eptr); } CATCH_LOG(); } while (0)\r\n<\/pre>\n
After all this discussion, maybe your conclusion is that when_all_completed<\/code> is just too weird, because it conflates exceptions that occur while producing or consuming the awaitables with exceptions that are produced by the awaitables themselves. And the correct answer is “Don’t use it. Just catch the exceptions in the awaitables themselves.”<\/p>\n
IAsyncAction First() try<\/span>\r\n{\r\n    \/* original body of the First() function *\/\r\n} CATCH_LOG();<\/span>\r\n\r\nIAsyncAction Second() try<\/span>\r\n{\r\n    \/* original body of the Second() function *\/\r\n} CATCH_LOG();<\/span>\r\n\r\nIAsyncAction Third() try<\/span>\r\n{\r\n    \/* original body of the Third() function *\/\r\n} CATCH_LOG();<\/span>\r\n\r\nfire_and_forget SomeFunction()\r\n{\r\n    co_await when_all(\r\n            First(), Second(), Third()));\r\n}\r\n<\/pre>\n
We caught the exceptions in the awaitables and ignored them (after logging). This means that when_all()<\/code> doesn’t have to report any exceptions in the awaitables, since we removed them. Any exceptions that come out of the line co_await when_all(First(), Second(), Third())<\/code> were the result either of producing or consuming the awaitables, and those are probably failures you want to treat as fatal errors since you have no reasonable way of recovering from them.<\/p>\n
There, I managed to convince myself that, after spending a very long time trying to write the when_all_complete<\/code> function, it was a bad idea after all.<\/p>\n
\u00b9 The Windows Runtime uses eager-start coroutines, so the coroutine starts on creation. If you use lazy-start coroutines, then the exception is thrown even before the coroutine starts, and you end up abandoning the coroutine without starting it. You don’t have the problem of a coroutine still running, but you do have the problem of a coroutine that never started.<\/p>\n","protected":false},"excerpt":{"rendered":"
The things that could go wrong before you even start.<\/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-108405","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
The things that could go wrong before you even start.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108405","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=108405"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108405\/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=108405"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=108405"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=108405"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}