{"id":11583,"date":"2011-02-04T07:00:00","date_gmt":"2011-02-04T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2011\/02\/04\/ready-cancel-wait-for-it-part-3\/"},"modified":"2011-02-04T07:00:00","modified_gmt":"2011-02-04T07:00:00","slug":"ready-cancel-wait-for-it-part-3","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20110204-00\/?p=11583","title":{"rendered":"Ready… cancel… wait for it! (part 3)"},"content":{"rendered":"

\nA customer reported that their application was crashing in RPC,\nand they submitted a sample program which illustrated the same\ncrash as their program.\nTheir sample program was actually based on the\nAsyncRPC sample client program, which was nice, because it\nprovided a mutually-known starting point.\nThey made quite a few changes to the program, but this is\nthe important one:\n<\/p>\n

\n\/\/ old code:\n\/\/ status = RpcAsyncCancelCall(&Async, FALSE);\n\/\/ new code:\n status = RpcAsyncCancelCall(&Async, TRUE);\n<\/pre>\n
\n(It was actually more complicated than this,\nbut this is the short version.)\n<\/p>\n
\nThe program was crashing for the same reason that\n\nWednesday’s I\/O cancellation program was crashing<\/a>:\nThe program issued an asynchronous cancel and didn’t\nwait for the cancel to complete.\nIn this case, the crash occurred when the RPC call\nfinally completed and RPC went about cleaning up the call\nbased on the information in the now-freed\nRPC_ASYNC_STATE<\/code> structure.\n<\/p>\n
\nThe error was probably caused by the not-very-helpful\nname for that last parameter to Rpc­Async­Cancel­Call<\/code>:\nfAbort­Call<\/code>,\nand the accompanying documentation which says,\n“In an abortive cancel (fAbort­Call<\/i> is TRUE),\nthe Rpc­Async­Cancel­Call<\/b> function sends a cancel\nnotification to the server and client side and the\nasynchronous call is canceled immediately,\nnot waiting for a response from the server.”\nCompare this to a nonabortive cancel,\nwhere “the Rpc­Async­Cancel­Call<\/b> function notifies\nthe server of the cancel and the client waits for the\nserver to complete the call.”\n<\/p>\n
\nObviously,\nit’s faster if you don’t wait for the server to respond, right?\nLet’s pass TRUE<\/code>, so that the function cancels the\nasynchronous call immediately without waiting for the server.\nWow, look at how fast our program runs now!\n<\/p>\n
\nUnfortunately,\nthe documentation doesn’t make it sufficiently clear\nthat when you issue a cancellation, you still have to\nwait for the operation to complete before you can clean up\nall the resources associated with that operation.\nAnother way of looking at that last parameter is to think\nof it as fAsync<\/code>.\nIf you pass fAsync = TRUE<\/code>,\nthen the\nRpc­Async­Cancel­Call<\/code>\nfunction issues the cancellation\nand returns before the operation completes.\nIf you pass fAsync = FALSE<\/code>,\nthen the\nRpc­Async­Cancel­Call<\/code>\nfunction issues the cancellation\nand waits for the operation to complete before returning.\n<\/p>\n
\nIf you switch from a synchronous cancel to an asynchronous cancel,\nthen you become responsible for keeping the\nRPC_ASYNC_STATE<\/code>\nvalid until the cancellation completes.\nIn this case, the customer was using the\nRpc­Notification­Type­Event<\/code> notification type,\nwhich means that they need to wait for the\nAsync.u.hEvent<\/code> to become signaled before they\ncan free the RPC_ASYNC_STATE<\/code>.\n<\/p>\n
\nThe customer confirmed the fix and closed the support case.\nAnother problem solved.\n<\/p>\n
\nThree months later, the customer reopened the case,\nreporting that after they released a new version of their\nprogram with the aforementioned fix,\nthey were nevertheless getting\nWinQual<\/a>\ncrashes which looked exactly like the ones that they were\nhaving before they applied the fix.\nIt appears that the fix wasn’t working.\n<\/p>\n
\nUpon closer investigation, it turns out that the customer\noriginally did apply the fix as recommended:\nThey added a\nWait­For­Single­Object(Async.u.hEvent, INFINITE)<\/code>\ncall before destroying the Async<\/code> object\nto ensure that the cancellation was complete.\nHowever, they became frustrated that sometimes the cancellation\nwould take a long time to complete, so they changed it to\n<\/p>\n
\nWaitForSingleObject(Async.u.hEvent, 5000); \/\/ wait up to 5 seconds\n<\/pre>\n
\nThe customer explained,\n“After the wait fails due to timeout,\nwe just proceed as normal and call\nRpc­Async­Complete­Call<\/code> and free the the\nRPC_ASYNC_STATE<\/code>. Is that wrong?”\n<\/p>\n
\nUm, yeah.\nChanging the\nWait­For­Single­Object<\/code>\nfrom an infinite wait\nto one with a timeout means that\nyou just reintroduced the bug that the\nWait­For­Single­Object<\/code>\nwas originally supposed to fix!\nIf the cancellation takes more than 5 seconds,\nthen your code will continue and free the\nRPC_ASYNC_STATE<\/code>,\njust like it did when you didn’t wait at all.\n<\/p>\n
\n“How long can I wait before assuming that the event will simply\nnever get signaled?”\n<\/p>\n
\nThere is no such duration after which you can safely abandon the operation.\nEven if the event doesn’t get signaled for 30 minutes\n(say because the computer is thrashing its guts out),\nit may get signaled at 30 minutes and 1 second.\n<\/p>\n
\n“But we don’t want our program to get stuck waiting for the server.”\n<\/p>\n
\nGreat.\nIt’s fine to have your program continues running after\nissuing the cancellation, even if the RPC call hasn’t completed.\nJust don’t free the RPC_ASYNC_STATE<\/code>\nuntil the call is complete.\nand if you set things up so that your completion event takes the\nform of a callback,\n\nyou can just make the callback free the\nRPC__ASYNC_STATE<\/code><\/a>.\nThen you don’t have to keep track of the asynchronous call any more;\nthe system will merely call you when it’s finished, and then you\ncan free the state structure.\n<\/p>\n
\nBonus RPC chatter<\/b>:\n(For the purpose of this discussion, I’ll use the term\nRPC operation<\/i> instead of RPC call<\/i> so we don’t have\nconfusion between function calls and RPC calls.)\nA colleague explained the lifetime of an RPC operation as follows:\n<\/p>\n\n\n\n\n\n\n\n\n
Submit phase<\/td>\nYou call into the MIDL-generated stub.<\/td>\nYou cannot call\n    Rpc­Async­Cancel­Call<\/code>\n    during the submit phase.<\/td>\n<\/tr>\n
The stub does magic RPC stuff.<\/td>\n<\/tr>\n
The stub returns control back to the caller.<\/td>\n<\/tr>\n
Pending phase<\/td>\nRPC is waiting for the response to the operation.\n    The operation remains in this phase until\n    the operation completes or is cancelled.\n<\/td>\nYou can call\n    Rpc­Async­Cancel­Call<\/code> to cancel the\n    RPC operation and accelerate the transition to the Notified phase.\n<\/td>\n<\/tr>\n
Notified phase<\/td>\nRPC informs the application of the result of the operation\n    in a manner described by the Notification­Type<\/code>\n    and RPC_ASYNC_NOTIFICATION_INFO<\/code> members of\n    the RPC_ASYNC_STATE<\/code> structure.\n<\/td>\nYou can call\n    Rpc­Async­Cancel­Call<\/code> but it will have no effect\n    since the operation is already complete.\n<\/td>\n<\/tr>\n
Completion phase<\/td>\nThe application calls\n    the Rpc­Async­Complete­Call<\/code> function to clean up\n    the resources used to track the RPC operation.\n    You exit the completion phase when\n    Rpc­Async­Complete­Call<\/code>\n    returns something other than\n    RPC_S_ASYNC_CALL_PENDING.\n<\/code><\/td>\nYou cannot call Rpc­Async­Cancel­Call<\/code> after\n    Rpc­Async­Complete­Call<\/code>\n    indicates that the operation\n    is complete, since that is the call that says “I’m all done!”\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","protected":false},"excerpt":{"rendered":"
A customer reported that their application was crashing in RPC, and they submitted a sample program which illustrated the same crash as their program. Their sample program was actually based on the AsyncRPC sample client program, which was nice, because it provided a mutually-known starting point. They made quite a few changes to the program, […]<\/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-11583","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
A customer reported that their application was crashing in RPC, and they submitted a sample program which illustrated the same crash as their program. Their sample program was actually based on the AsyncRPC sample client program, which was nice, because it provided a mutually-known starting point. They made quite a few changes to the program, […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/11583","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=11583"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/11583\/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=11583"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=11583"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=11583"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}