{"id":109963,"date":"2024-07-10T07:00:00","date_gmt":"2024-07-10T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=109963"},"modified":"2024-06-24T10:37:48","modified_gmt":"2024-06-24T17:37:48","slug":"20240710-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20240710-00\/?p=109963","title":{"rendered":"Creating an already-completed asynchronous activity in C++\/WinRT, part 2"},"content":{"rendered":"

Last time, we tried to create an already-completed asynchronous activity in C++\/WinRT<\/a>. We were able to create a coroutine that represented a successful already-completed operation:<\/p>\n

winrt::Windows::Foundation::IAsyncOperation<int>\r\n    ComputeAsync()\r\n{\r\n    co_return 42;\r\n}\r\n<\/pre>\n
But the analogous function for creating a failed already-completed operation didn’t work because its lack of any co_await<\/code> or co_return<\/code> statement means that it wasn’t a coroutine at all!<\/p>\n
winrt::Windows::Foundation::IAsyncOperation<int>\r\n    ComputeAsync()\r\n{\r\n    throw winrt::hresult_access_denied();\r\n}\r\n<\/pre>\n
To make the function a coroutine, we need to put a co_await<\/code> or co_return<\/code> in the body somewhere. We have a few options.<\/p>\n
One is to put the co_await<\/code> after the throw<\/code>, so it is physically present in the function body (thereby making it a coroutine), but is unreachable. A safe thing to await is std::suspend_never()<\/code>, which is a built-in awaitable that never awaits.<\/p>\n
winrt::Windows::Foundation::IAsyncOperation<int>\r\n    ComputeAsync()\r\n{\r\n    throw winrt::hresult_access_denied();\r\n    co_await std::suspend_never();<\/span>\r\n}\r\n<\/pre>\n
Perhaps a more reasonable thing is to actually try to co_return<\/code> something.<\/p>\n
winrt::Windows::Foundation::IAsyncOperation<int>\r\n    ComputeAsync()\r\n{\r\n    throw winrt::hresult_access_denied();\r\n    co_return 0;<\/span>\r\n}\r\n<\/pre>\n
Both of these work, and it appears that the major compilers (gcc, clang, msvc) all optimize out the code that follows a throw<\/code>. And as of this writing, they also do not raise a dead code diagnostic, though that’s the thing that worries me: It’s possible that a future version of the compiler will decide to produce dead code diagnostics, and then this code will cause problems when used in code bases that treat warnings as errors.<\/p>\n
We can put a co_await<\/code> in front of the throw<\/code>, but again, if we put it in a dead code block, we risk a diagnostic:<\/p>\n
winrt::Windows::Foundation::IAsyncOperation<int>\r\n    ComputeAsync()\r\n{\r\n    if (false) co_return 0;<\/span>\r\n    throw winrt::hresult_access_denied();\r\n}\r\n<\/pre>\n
So maybe the thing to do is actually co_await<\/code> something, but await something that does nothing. That’s where we can use the built-in suspend_never<\/code>.<\/p>\n
winrt::Windows::Foundation::IAsyncOperation<int>\r\n    ComputeAsync()\r\n{\r\n    co_await std::suspend_never{};<\/span>\r\n    throw winrt::hresult_access_denied();\r\n}\r\n<\/pre>\n
The major compilers recognize this pattern, and it’s not dead code, so we don’t risk an unreachable code diagnostic.<\/p>\n
But wait, it’s still a problem, thanks to our pal await_transform<\/code>. The C++\/WinRT implementation of await_transform<\/code> for Windows Runtime IAsyncXxx<\/code> interfaces wraps all awaitables inside an awaiter that check whether the IAsyncXxx<\/code> has been cancelled and throws an hresult_canceled<\/code> exception if so.<\/p>\n
Now, we know that the coroutine is never cancelled before it completes, but the compilers’ escape analysis can’t see that, so in practice, they will include that extra check. The co_await std::suspend_never{}<\/code> cannot be optimized out entirely.<\/p>\n
At this point, you have to go looking for a rabbit to pull out of your hat. And in this case, the rabbit is winrt::cancellation_token<\/code>.<\/p>\n
The winrt::cancellation_token<\/code> is a sentinel object that is not generally awaitable, but C++\/WinRT’s implementation of IAsyncXxx<\/code> recognizes it as as a special awaitable in its await_transform<\/code> and (here’s where the rabbit comes from) the custom awaiter returns an object (which is just a wrapper around a pointer to the promise) without any other fanfare.<\/p>\n
The trick, therefore, is to await the cancellation token and  discard the resulting object<\/a>.<\/p>\n
winrt::Windows::Foundation::IAsyncOperation<int>\r\n    ComputeAsync()\r\n{\r\n    (void)co_await winrt::get_cancellation_token();<\/span>\r\n\r\n    throw winrt::hresult_access_denied();\r\n}\r\n<\/pre>\n
We explicitly discard the result of the co_await<\/code>, just in case some future version of C++\/WinRT adds the [[nodiscard]]<\/code> attribute.<\/p>\n
Now that we know how to code up this specific case, we’ll work on generalizing it next time.<\/p>\n","protected":false},"excerpt":{"rendered":"
Making our function a coroutine.<\/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-109963","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Making our function a coroutine.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/109963","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=109963"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/109963\/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=109963"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=109963"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=109963"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}