{"id":107772,"date":"2023-02-01T07:00:00","date_gmt":"2023-02-01T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=107772"},"modified":"2023-01-30T19:55:39","modified_gmt":"2023-01-31T03:55:39","slug":"20230201-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20230201-00\/?p=107772","title":{"rendered":"Inside C++\/WinRT: Coroutine completion handlers: Disconnection"},"content":{"rendered":"

C++\/WinRT relies on the Completed<\/code> delegate to tell it when a Windows Runtime asynchronous operation is complete. However, it’s possible that the IAsyncAction<\/code> or IAsyncOperation<\/code> provider tears itself down without ever calling the Completed<\/code> handler. This typically happens when the provider is running in another process that crashes (or at least disconnects from you<\/a>). It never calls its completion handler, and the coroutine simple gets leaked.<\/p>\n

Here’s what you see in the debugger:<\/p>\n

contoso!winrt::impl::implements_delegate<AsyncActionCompletedHandler,lambda_xxxx>::Release+0x64\r\ncombase!<lambda_yyy>::operator()+0xd7\r\ncombase!ObjectMethodExceptionHandlingAction<<lambda_yyy> >+0xe\r\ncombase!CStdIdentity::ReleaseCtrlUnk+0x64\r\ncombase!CStdMarshal::DisconnectWorker_ReleasesLock+0x6e7\r\ncombase!CStdMarshal::DisconnectAndReleaseWorker_ReleasesLock+0x35\r\ncombase!CStdMarshal::DisconnectForRundownIfAppropriate+0xc9\r\ncombase!CRemoteUnknown::RundownOidWorker+0x241\r\ncombase!CRemoteUnknown::RundownOid+0x65\r\nRPCRT4!Invoke+0x73\r\nRPCRT4!NdrStubCall2+0x3db\r\nRPCRT4!NdrStubCall3+0xee\r\ncombase!CStdStubBuffer_Invoke+0x6f\r\ncombase!InvokeStubWithExceptionPolicyAndTracing::__l6::<lambda_zzz>::operator()+0x22\r\ncombase!ObjectMethodExceptionHandlingAction<<lambda_zzz> >+0x4d\r\ncombase!InvokeStubWithExceptionPolicyAndTracing+0xe1\r\ncombase!DefaultStubInvoke+0x268\r\ncombase!SyncServerCall::StubInvoke+0x41\r\ncombase!StubInvoke+0x303\r\ncombase!ServerCall::ContextInvoke+0x517\r\ncombase!ComInvokeWithLockAndIPID+0x9a9\r\ncombase!ThreadInvokeReturnHresult+0x17b\r\ncombase!ThreadInvoke+0x193\r\nRPCRT4!DispatchToStubInCNoAvrf+0x22\r\nRPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x1b4\r\nRPCRT4!RPC_INTERFACE::DispatchToStub+0xb3\r\nRPCRT4!RPC_INTERFACE::DispatchToStubWithObject+0x188\r\nRPCRT4!LRPC_SBINDING::DispatchToStubWithObject+0x23\r\nRPCRT4!LRPC_SCALL::DispatchRequest+0x14c\r\nRPCRT4!LRPC_SCALL::QueueOrDispatchCall+0x253\r\nRPCRT4!LRPC_SCALL::HandleRequest+0x996\r\nRPCRT4!LRPC_SASSOCIATION::HandleRequest+0x2c3\r\nRPCRT4!LRPC_ADDRESS::HandleRequest+0x17c\r\nRPCRT4!LRPC_ADDRESS::ProcessIO+0x939\r\nRPCRT4!LrpcIoComplete+0x109\r\nntdll!TppAlpcpExecuteCallback+0x157\r\nntdll!TppWorkerThread+0x72c\r\nKERNEL32!BaseThreadInitThunk+0x1d\r\nntdll!RtlUserThreadStart+0x28\r\n<\/pre>\n
The way we address this is to have the completion handler detect that it was never invoked. If that happens, then it simply invokes itself. On resumption, the coroutine will call GetResults()<\/code> on the asynchronous operation, and that will throw the appropriate RPC error.<\/p>\n
Keeping track of whether the handler was invoked requires a custom destructor, so we’ll convert the lambda to a C++ class first, so that we can add a destructor. This conversion is mechanical.<\/p>\n
\/\/ Original lambda\r\n[\r\n    handle,\r\n    this,\r\n    context = resume_apartment_context()\r\n](auto&& ...)\r\n{\r\n    resume_apartment(context.context, handle,\r\n        &failure);\r\n});\r\n\r\n\/\/ Converted to explicit class\r\n\r\ntemplate<typename Awaiter>\r\nstruct disconnect_aware_handler\r\n{\r\n    disconnect_aware_handler(Awaiter* awaiter,\r\n        coroutine_handle<> handle) noexcept\r\n        m_awaiter(awaiter), m_handle(handle) {}\r\n\r\n    template<typename...Args>\r\n    void operator()(Args&&...)\r\n    {\r\n        resume_apartment(m_context.context, m_handle,\r\n            &m_awaiter->failure);\r\n    }\r\n\r\nprivate:\r\n    Awaiter* m_awaiter;\r\n    coroutine_handle<> m_handle;\r\n    resume_apartment_context m_context;\r\n};\r\n\r\ntemplate<typename Async>\r\nstruct await_adapter\r\n{\r\n    \u301a ... \u301b\r\n\r\n    void await_suspend(coroutine_handle<> handle) const\r\n    {\r\n        auto extend_lifetime = async;\r\n        async.Completed(\r\n            disconnect_aware_handler(this, handle)<\/span>);\r\n    }\r\n\r\n    \u301a ... \u301b\r\n};\r\n<\/pre>\n
Okay, now we can add a destructor that calls the operator()<\/code> if it had never been called. We’ll factor the body into a method Complete()<\/code> and use the null-ness of the m_handle<\/code> to tell us whether the operator has been invoked yet.<\/p>\n
template<typename Awaiter>\r\nstruct disconnect_aware_handler\r\n{\r\n    disconnect_aware_handler(Awaiter* awaiter,\r\n        coroutine_handle<> handle) noexcept\r\n        m_awaiter(awaiter), m_handle(handle) {}\r\n\r\n    ~disconnect_aware_handler()\r\n    {\r\n        if (m_handle) Complete();\r\n    }<\/span>\r\n\r\n    template<typename...Args>\r\n    void operator()(Args&&...)\r\n    {\r\n        Complete();<\/span>\r\n    }\r\n\r\nprivate:\r\n    Awaiter* m_awaiter;\r\n    coroutine_handle<> m_handle;\r\n    resume_apartment_context m_context;\r\n\r\n    void Complete()\r\n    {<\/span>\r\n        resume_apartment(m_context.context,\r\n            std::exchange(m_handle, {})<\/span>,\r\n            &m_awaiter->failure);\r\n    }<\/span>\r\n};\r\n<\/pre>\n
If you try this, though, it fails miserably: The delegate constructor moves the functor into the newly-constructed delegate, but coroutine_handle<\/code>‘s move constructor simply copies the coroutine handle. This means that when the delegate constructor moves the functor, the temporary functor destructs and says, “Oh no, I was never invoked! I must have been disconnected!”, and it resumes the coroutine. And then when the coroutine completes for real, the invoke occurs a second time, and we have resumed a running coroutine, which is illegal.<\/p>\n
    disconnect_aware_handler(disconnect_aware_handler&& other) noexcept\r\n        : m_context(std::move(other.m_context))\r\n        , m_awaiter(std::exchange(other.m_awaiter, {}))\r\n        , m_handle(std::exchange(other.m_handle, {})) { }\r\n<\/pre>\n
We null out the m_awaiter<\/code> just for good measure.<\/p>\n
If you see a coroutine resumption from disconnect_aware_handler<\/code>‘s destructor when debugging, then that is a sign that the coroutine is resuming due to a disconnection from the Windows Runtime asynchronous operation provider.<\/p>\n","protected":false},"excerpt":{"rendered":"
When the other end hangs up without even saying good-bye.<\/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-107772","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
When the other end hangs up without even saying good-bye.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107772","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=107772"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107772\/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=107772"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=107772"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=107772"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
We need custom move operators that null out the coroutine handle in the moved-from object. This is another case where we could have used the  movable_primitive<\/code> template type<\/a>, but C++\/WinRT just writes it out by hand.<\/p>\n