{"id":108389,"date":"2023-07-04T07:00:00","date_gmt":"2023-07-04T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=108389"},"modified":"2023-07-31T11:09:48","modified_gmt":"2023-07-31T18:09:48","slug":"20230704-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20230704-00\/?p=108389","title":{"rendered":"How to wait for multiple C++ coroutines to complete before propagating failure, memory allocation failure"},"content":{"rendered":"

Last time, we used symmetric transfer to avoid stack build-up<\/a> when calling back and forth between the outer driver function when_all_completed<\/code> and the coroutine created from our custom promise. But we lost sight of the original reason for using the custom promise, which was to allow us to deal with memory allocations.<\/p>\n

The concern we had was that if a memory allocation error occurred when allocating the coroutine frame, the runtime normally throws std::bad_alloc<\/code>, and the coroutine body never runs. Furthermore, we currently do not distinguish between an allocation failure in the creation of the coroutine, as opposed to an allocation failure that was thrown from the coroutine body.<\/p>\n

One way to deal with this is to catch the initial coroutine creation, separately from co_await<\/code>ing it.<\/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 capture_exception = [](auto& async)\r\n        -> all_completed_result {\r\n        co_await std::move(async);\r\n    };\r\n\r\n    auto ensure_alloc = [&](auto& async) noexcept<\/span>\r\n    {                                            <\/span>\r\n        return capture_exception(async);         <\/span>\r\n    };                                           <\/span>\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 ensure_alloc<\/span>(asyncs)), ...);\r\n\r\n    if (eptr) std::rethrow_exception(eptr);\r\n}\r\n<\/pre>\n
If a memory allocation failure occurs when trying to allocate the coroutine frame, then the std::bad_alloc<\/code> is thrown out of the initial call to capture_exception()<\/code>. The noexcept<\/code> on the ensure_alloc<\/code> converts this exception into a std::terminate<\/code>, and the program fails fast.<\/p>\n
We are unable to make forward progress, and throwing an exception from when_all_completed<\/code> would be misinterpreted as propagating an exception from one of the awaitables. The only remaining option is to simply terminate the process.<\/p>\n
An alternate solution is to encode the “terminate on std::bad_alloc<\/code> trying to allocate the coroutine frame” in the promise itself. If the promise has a custom operator new<\/code>, then that custom operator is used to allocate the coroutine frame. (Similarly, a custom operator delete<\/code> is used to deallocate the coroutine frame.)<\/p>\n
Therefore, instead of modifying when_all_completed<\/code>, we can modify the all_completed_promise<\/code>:\u00b9<\/p>\n
struct all_completed_promise\r\n{\r\n    ...\r\n\r\n    \/\/ Fail fast if unable to allocate the coroutine frame.<\/span>\r\n    void* operator new(std::size_t n) try {                <\/span>\r\n        return ::operator new(n);                          <\/span>\r\n    } catch (...) { std::terminate(); }                    <\/span>\r\n};\r\n<\/pre>\n
Another option might be to invent a special exception that means “Sorry, I was unable to perform the requested operation. The awaitables have not necessarily all run to completion.”<\/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 capture_exception = [](auto& async)\r\n        -> all_completed_result {\r\n        co_await std::move(async);\r\n    };\r\n\r\n    auto ensure_alloc = [&](auto& async) try<\/span>\r\n    {\r\n        return capture_exception(async);\r\n    } catch (...) {                                     <\/span>\r\n        throw winrt::hresult_error(                     <\/span>\r\n            HRESULT_FROM_WIN32(ERROR_CAN_NOT_COMPLETE));<\/span>\r\n    };\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 ensure_alloc(asyncs)), ...);\r\n\r\n    if (eptr) std::rethrow_exception(eptr);\r\n}\r\n<\/pre>\n
Or, if you prefer to apply this policy in the promise:<\/p>\n
struct all_completed_promise\r\n{\r\n    ...\r\n\r\n    void* operator new(std::size_t n) try<\/span> {\r\n        return ::operator new(n);\r\n    } catch (...) {                                     <\/span>\r\n        throw winrt::hresult_error(                     <\/span>\r\n            HRESULT_FROM_WIN32(ERROR_CAN_NOT_COMPLETE));<\/span>\r\n    };\r\n};\r\n<\/pre>\n
And now you can document that ERROR_CAN_NOT_COMPLETE<\/code> is the error code that means, “Sorry, I was not able to perform the required duties.”<\/p>\n
I’m not sure this special exception is warranted, however, because there’s no way for the caller to recover. I mean, you call this function to wait for all of the operations to complete, and it says “Sorry, I couldn’t do that.” Now what are you going to do? The operations haven’t run to completion. You can’t perform the next step in your algorithm. But you can’t just give up now, because you want to make sure those operations are complete and won’t create race conditions.<\/p>\n
You’re stuck between the same rock and hard place that the when_all_complete<\/code> function found itself in, and your options are the same: Either fail fast now, or tell the caller “Hi, so something is fatally, unrecoverably wrong, and there’s no point continuing because if you do, there is going to be memory corruption and race conditions and all sorts of badness.”<\/p>\n
And what’s your caller going to do? Either fail fast or pass the buck to its caller.<\/p>\n
Eventually, there will be nobody left to pass the buck to, and the program will terminate with an unhandled exception. Even worse, the termination will occur at a point far, far away from the root cause, so the poor developer who gets stuck with the unhandled exception is going to have quite an unwanted adventure trying to figure out what happened.<\/p>\n
May as well save everyone the trouble of trying to deal with a problem that they cannot recover from. Fail fast right away so you can identify the root cause quickly.<\/p>\n
Next time, we’ll try to take the dynamic memory allocation out of this entire scenario.<\/p>\n
\u00b9 You’d think you could write<\/p>\n
    \/\/ Fail fast if unable to allocate the coroutine frame.\r\n    void* operator new(std::size_t n) noexcept<\/span> {\r\n        return ::operator new(n);\r\n    }\r\n<\/pre>\n
so that any exception thrown by ::operator new<\/code> terminates the process. This does work, but a noexcept<\/code> operator new<\/code> tells the compiler that it will return nullptr<\/code> on memory allocation failure, in which case the compiler will call a developer-provided get_return_object_on_allocation_failure()<\/code> function to produce the all_completed_result<\/code> that will be returned by the (nonexistent) coroutine. Therefore, if we apply noexcept<\/code> to our custom operator new<\/code>, we also have to provide a get_return_object_on_allocation_failure()<\/code> function. Removing the noexcept<\/code> from our operator new<\/code> avoids this requirement.<\/p>\n","protected":false},"excerpt":{"rendered":"
There’s no good way to report the failure, so we just have to give up.<\/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-108389","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
There’s no good way to report the failure, so we just have to give up.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108389","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=108389"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108389\/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=108389"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=108389"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=108389"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}