{"id":107779,"date":"2023-02-02T07:00:00","date_gmt":"2023-02-02T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=107779"},"modified":"2023-02-01T20:26:15","modified_gmt":"2023-02-02T04:26:15","slug":"20230202-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20230202-00\/?p=107779","title":{"rendered":"Inside C++\/WinRT: Coroutine completions: Avoiding reentrant completion"},"content":{"rendered":"

If a Windows Runtime asynchronous operation has already completed at the point the Completed<\/code> delegate is assigned, the implementation is permitted to invoke the delegate before returning from the assignment.<\/p>\n

The way we have set things up so far, it means that the awaiting an already-completed Windows Runtime asynchronous operation results in a chain of calls:<\/p>\n

MyAwesomeCoroutine::DoSomethingAsync$Resu\r\ncoroutine_handle<>::resume\r\nresume_apartment\r\ndisconnect_aware_handler::Complete\r\nProvider::FireCompletion\r\nProvider::put_Completed\r\nIAsyncOperation::put_Completed\r\nawait_adapter::await_suspend\r\nMyAwesomeCoroutine::DoSomethingAsync$Resu\r\n<\/pre>\n
All those stack frames between the two My\u00adAwesome\u00adCoroutine::Do\u00adSomething\u00adAsync$Resu<\/code> frames are unnecessary, and if you are co_await<\/code>‘ing in a loop, the stack usage accumulates and can result in unexpected stack exhaustion.<\/p>\n
What we can do is detect that the completion handler is running before put_Completed<\/code> has returned, and in that case, we merely remember that the coroutine needs to resume, but without actually resuming it immediately. We allow execution to unwind back to await_suspend<\/code> and then return false<\/code> to tell the coroutine infrastructure to resume the coroutine when it unwinds.<\/p>\n
template<typename Awaiter>\r\nstruct disconnect_aware_handler\r\n{\r\n    \u301a ... \u301b\r\n\r\n    void Complete()\r\n    {\r\n        if (m_awaiter->suspending\r\n            .exchange(false, std::memory_order_release))\r\n        {\r\n            \/\/ resumption has been deferred to await_suspend\r\n            m_handle = nullptr;\r\n        }\r\n        else\r\n        {<\/span>\r\n            resume_apartment(m_context.context,\r\n                std::exchange(m_handle, {}),\r\n                &m_awaiter->failure);\r\n        }<\/span>\r\n    }\r\n};\r\n<\/pre>\n
If the awaiter says that it’s still suspending, then don’t resume immediately. Instead, reset the suspending<\/code> to false<\/code> to tell await_suspend<\/code> to cancel the suspension.<\/p>\n
template<typename Async>\r\nstruct await_adapter\r\n{\r\n    await_adapter(Async const& async) : async(async) { }\r\n\r\n    Async const& async;\r\n    int32_t failure = 0;\r\n    std::atomic<bool> suspending = true;<\/span>\r\n\r\n    \u301a ... \u301b\r\n\r\n    auto<\/span> await_suspend(coroutine_handle<> handle) const\r\n    {\r\n         \/\/ auto extend_lifetime = async;<\/span><\/span>\r\n        async.Completed(\r\n            disconnect_aware_handler(this, handle));\r\n        return suspending.exchange(false, std::memory_order_acquire);<\/span>\r\n    }\r\n\r\n    \u301a ... \u301b\r\n};\r\n<\/pre>\n
The other half of the communication is in the await_adapter<\/code>‘s await_suspend<\/code> method. After setting the Completed<\/code> handler, we reset suspending<\/code> to false<\/code>, and return the previous value. The previous value is true<\/code> if the completion handler hasn’t run yet, and returning true<\/code> from await_suspend<\/code> allows the suspension to proceed. But if the completion handler has already run, then the previous value is false<\/code>, and returning handler hasn’t run yet, and returning false<\/code> from await_suspend<\/code> tells the coroutine infrastructure to abandon the suspension and resume the coroutine.<\/p>\n
Note that we use atomic operations on both sides, because the completion handler might run on another thread and race against await_suspend<\/code>. In particular, we need to watch out for the case where the completion handler is called immediately after await_suspend<\/code> sets the Completed<\/code> property and checks the suspending<\/code> variable, but before it returns. In that case, we need to resume the coroutine immediately from the completion handler, because the decision to allow the coroutine to suspend has already been made.<\/p>\n
The atomic operations use release semantics on the publishing side and acquire semantics on the consumption side so that any changes to objects immediately before completion are visible when the coroutine resumes.<\/p>\n
Now that we defer the resumption of the coroutine until after async.Completed()<\/code> returns, we don’t need to extend its lifetime to protect against premature resumption: We never resume the coroutine while async.Completed()<\/code> is still running.<\/p>\n
As of this writing, C++\/WinRT still supports Visual C++’s experimental coroutine support. Older versions of that coroutine support have a code generation bug (which  I noted some time ago<\/a> is  fixed in versions 16.11 and 17.0<\/a>), so we need to work around that. The way to detect the experimental coroutine support is to check for the preprocessor symbol _RESUMABLE_FUNCTIONS_SUPPORTED<\/code>:<\/p>\n
template<typename Async>\r\nstruct await_adapter\r\n{\r\n    \u301a ... \u301b\r\n\r\n    auto await_suspend(coroutine_handle<> handle) const\r\n    {\r\n        async.Completed(\r\n            disconnect_aware_handler(this, handle));\r\n#ifdef _RESUMABLE_FUNCTIONS_SUPPORTED\r\n        if (!suspending.exchange(false, std::memory_order_acquire))\r\n        {\r\n            handle.resume();\r\n        }\r\n#else<\/span>\r\n        return suspending.exchange(false, std::memory_order_acquire);\r\n#endif<\/span>\r\n    }\r\n\r\n    \u301a ... \u301b\r\n};\r\n<\/pre>\n
If we are being compiled with experimental coroutine support, then we avoid the code generation bug by resuming the handle explicitly rather than returning a bool<\/code>. This does consume a little bit or stack, but not as much as before.<\/p>\n
Bonus chatter<\/b>: The workaround is used if experimental coroutine support is detected, regardless of the Visual C++ compiler version. That’s because the experimental coroutines are all ABI compatible, and I don’t want to take the risk of an ODR violation if people link together object files compiled with different versions of experimental coroutine support.  Visual C++ took an ABI breaking change for standard coroutines<\/a>, so C++\/WinRT uses that as its own signal to switch to the bool<\/code> version of await_suspend<\/code>. That way, there won’t be any ODR violation in C++\/WinRT caused by linking together object files with experimental and standard coroutines: If you try, you get  a mismatch from MSVC for _COROUTINE_ABI<\/code>. Combining experimental and standard coroutines never worked anyway, and we rely on the compiler to check for us.<\/p>\n","protected":false},"excerpt":{"rendered":"
Resuming the coroutine directly, rather than consuming yet more stack.<\/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-107779","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Resuming the coroutine directly, rather than consuming yet more stack.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107779","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=107779"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107779\/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=107779"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=107779"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=107779"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}