Today is a puzzle you can you can try to solve with the information you’ve learned about C++ coroutines and C++\/WinRT.<\/p>\n
C++\/WinRT uses the The basic idea goes like this:<\/p>\n Maybe you see a problem here. I noticed a problem when I studied the C++\/WinRT code and meant to do a write-up on it eventually, but then I actually ran into the problem and alerted Kenny<\/a>, who promptly fixed it<\/a>. (Note: Clicking through gives away the answer.)<\/p>\n The In the above diagram, code inside a box represents code being executed on behavior of a coroutine. If the thread does not have a box, then it is available to do other work.<\/p>\n A synchronous callback means that when this awaiter tries to resume execution, the thread that raised the This shaded period during which the thread is unresponsive may last for a long time. And that’s a problem if it’s a UI thread.<\/p>\n Consider the following scenario:<\/p>\n This coroutine switches immediately to a background thread, does a bunch of work, and then switches back to the UI thread to update some UI.<\/p>\n You might decide to use this function like this:<\/p>\n In C++\/WinRT, Let’s look more closely at what happens.<\/p>\n The first part of the sequence goes as you would expect. The Next, it calls Once rescheduled (redundantly) on a background thread, it does some background work. Again, this background work can take a long time, but that’s okay because we’re on a background thread.<\/p>\n When the background work is done, Once back on the UI thread, Now things get interesting.<\/p>\n The awaiter for The And it’s true that long blocking operations are permitted on a background thread. The problem is that a UI thread is waiting for the background thread.<\/p>\n The background thread is unwittingly holding up a UI thread.<\/p>\nIContext\u00adCallback<\/code> interface to remember the context that initiated a co_await<\/code> operation<\/a>, so it can resume execution in the original apartment when the co_await<\/code> completes.<\/p>\nvoid await_suspend(std::experimental::coroutine_handle<> handle)\r\n{\r\n async.Completed([handle,\r\n context = CaptureCurrentApartmentContext()<\/span>]\r\n (auto const&, Windows::Foundation::AsyncStatus)\r\n {\r\n \/\/ When the operation completes, get back to the\r\n \/\/ original apartment and resume the coroutine there.\r\n check_hresult(InvokeInContext<\/a>(context.get(), handle));\r\n });\r\n}\r\n<\/pre>\nIContext\u00adCallback::<\/code>Context\u00adCallback<\/code> method invokes the callback synchronously, and the invoking apartment is stuck waiting for the result. This is good if you want to callback to do some work that you are waiting for, but it’s not good if the caller just wants to fire and forget.<\/p>\n\n\n
\n Thread 1<\/th>\n \u00a0<\/td>\n Thread 2<\/th>\n<\/tr>\n \n co_await something;<\/code>
\nawait_suspend();<\/code><\/td>\n<\/tr>\n\n operation continues<\/td>\n<\/tr>\n \n <\/td>\n operation completes
\nInvokeInContext<\/code><\/td>\n<\/tr>\n\n handle();<\/code>
\ncoroutine runs to next
\n\u2003suspension point<\/td>\nblocked in
\nInvokeInContext<\/td>\n<\/tr>\n\n <\/td>\n InvokeInContext<\/code> returns<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nCompleted<\/code> event is stuck until the continued coroutine reaches a suspension point or completes, because those are the things that cause the coroutine to return at the ABI. This period of time is represented by the shaded section labeled “blocked in Invoke\u00adIn\u00adContext”. During this period, the thread is not available to do work.<\/p>\nIAsyncAction SomethingAsync()\r\n{\r\n co_await resume_background();\r\n\r\n DoBackgroundWork();\r\n\r\n \/\/ Get to our UI thread so we can update UI.\r\n co_await resume_foreground(Dispatcher());\r\n\r\n UpdateUIStuff();\r\n\r\n co_return;\r\n}\r\n<\/pre>\nIAsyncAction SomethingMoreAsync()\r\n{\r\n \/\/ Do all our work on a background thread.\r\n co_await resume_background();\r\n\r\n LongBlockingOperation();\r\n co_await SomethingAsync();\r\n LongBlockingOperation();\r\n}\r\n<\/pre>\nco_await<\/code> of an IAsync\u00adAction<\/code> returns control to the same apartment that originated the operation, so all of the Long\u00adBlocking\u00adOperation<\/code> calls occur on a background thread. Certainly it’s safe to perform long blocking operations on a background thread, right?<\/p>\n\n\n
\n UI thread<\/th>\n \u00a0<\/td>\n Background thread<\/th>\n<\/tr>\n \n SomethingMoreAsync<\/code> begins
\nco_await resume_background();<\/code><\/td>\n<\/tr>\n\n <\/td>\n SomethingMoreAsync<\/code> resumes<\/td>\n<\/tr>\n\n <\/td>\n LongBlockingOperation()<\/code><\/td>\n<\/tr>\n\n <\/td>\n SomethingAsync<\/code> begins
\nco_await resume_background();<\/code><\/td>\n<\/tr>\n\n <\/td>\n \u00a0<\/td>\n<\/tr>\n \n <\/td>\n SomethingAsync<\/code> resumes<\/td>\n<\/tr>\n\n <\/td>\n DoBackgroundWork()<\/code><\/td>\n<\/tr>\n\n <\/td>\n co_await resume_foreground();<\/code><\/td>\n<\/tr>\n\n SomethingAsync<\/code> resumes
\nUpdateUIStuff();<\/code>
\nSomethingAsync<\/code> completes
\nCompleted()<\/code> handler tries to
\n\u2003resume on original context
\nInvokeInContext<\/code><\/td>\n\u21d0<\/span> things get interesting<\/td>\n<\/tr>\n \n blocked in
\nInvokeInContext<\/td>\nhandle();<\/code>
\nSomethingMoreAsync<\/code> resumes<\/td>\n<\/tr>\n\n LongBlockingOperation()<\/code><\/td>\n<\/tr>\n\n SomethingMoreAsync<\/code> completes<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nSomething\u00adMore\u00adAsync<\/code> coroutine moves to a background thread and performs a long blocking operation. This is okay, because we’re on a background thread.<\/p>\nSomething\u00adAsync<\/code>, which starts by moving to a background thread. (It’s already on a background thread, but it doesn’t know that.)<\/p>\nSomething\u00adAsync<\/code> moves back to the UI thread.<\/p>\nSomething\u00adAsync<\/code> updates its UI and completes the coroutine.<\/p>\nIAsyncAction<\/code> wants to resume in the original apartment, which in this case means going back to a background thread. It does this by using IContext\u00adCallback::<\/code>Context\u00adCallback<\/code>, which we wrapped inside Invoke\u00adIn\u00adContext<\/code> for expository purposes.<\/p>\nIContext\u00adCallback::<\/code>Context\u00adCallback<\/code> method invokes the callback synchronously, which means in our case that the call doesn’t return until the resumed coroutine reaches its next suspension point. But before it can complete or perform another co_await<\/code>, it performs a long blocking operation, believing that since it is on a background thread, long blocking operations are permitted.<\/p>\n