{"id":100725,"date":"2019-01-17T07:00:00","date_gmt":"2019-01-17T22:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=100725"},"modified":"2021-02-08T17:21:08","modified_gmt":"2021-02-09T01:21:08","slug":"20190117-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20190117-00\/?p=100725","title":{"rendered":"How do I get the effect of C#’s async void in a C++ coroutine? Part 2: Keeping track of the lifetimes"},"content":{"rendered":"

Last time<\/a>, we looked at how to write a function that formally returns void<\/code> that nevertheless performs co_await<\/code> operations. The function acts like a fire-and-forget, where the remainder of the task runs asynchronously after the first co_await<\/code> that needs to suspend.<\/p>\n

To recap: We saw that the obvious single-function solution fails because of lifetime issues:<\/p>\n

\/\/ Code in italics is wrong.\r\nvoid MyEventHandler(int a, int b)\r\n{\r\n  [=]() -> Concurrency::task<void><\/i>\r\n  {<\/span>\r\n    GetReady(a);\r\n    co_await GetSetAsync(b);\r\n    Go(a, b);\r\n  }();<\/span>\r\n}\r\n<\/pre>\n
The problem is that the lambda is destroyed when the function returns, and then when the task tries to access it, it ends up trying to use a detroyed object, and that doesn’t end well.<\/p>\n
Functions that are converted to coroutines capture the function parameters and their local variables in a frame. The frame consists of the function’s formal parameters and local variables, so we need to transfer the captured things into the frame:<\/p>\n
void MyClass::MyEventHandler(int a, int b)\r\n{\r\n  [](std::shared_ptr<MyClass> self, int a, int b)\r\n   -> Concurrency::task<void>\r\n  {\r\n   self->GetReady(a);\r\n   co_await self->GetSetAsync(b);\r\n   self->Go(a, b);\r\n  }(this->shared_from_this(), a, b);\r\n}\r\n<\/pre>\n
However, this forces us to repeat self<\/code> all the time. What we want is a way to get this<\/code> to refer to the class whose method we are in, so we won’t have to do this self<\/code> nonsense. But we also want a captureless lambda, so we won’t have the problem of a task trying to access a destroyed lambda.<\/p>\n
This is a contradiction. If you have a captureless lambda, then it cannot capture this<\/code>. The problem looks hopeless.<\/p>\n
Until you realize that there’s nobody forcing you to do it all in just one lambda.<\/p>\n
So let’s use two lambdas. One of them captures this<\/code> so it doesn’t have to carry self<\/code> around. And then we put that lambda into the frame of the second lambda and invoke it. Then we invoke the second lambda to get the party started.<\/p>\n
void MyClass::MyEventHandler(int a, int b)\r\n{\r\n  auto lambda1 =\r\n   [=, lifetime = this->shared_from_this()]()\r\n   -> Concurrency::task<void>\r\n  {\r\n   GetReady(a);\r\n   co_await GetSetAsync(b);\r\n   Go(a, b);\r\n  };\r\n\r\n  auto lambda2 = [](auto lambda1)\r\n   -> Concurrency::task<void>\r\n  {\r\n   co_await lambda1();\r\n  };\r\n\r\n  lambda2(lambda1);\r\n}\r\n<\/pre>\n
The first lambda is the one we wish we could use. It captures anything it wants, and can co_await<\/code> for whatever it likes. To ensure that this<\/code> doesn’t disappear out from under it, we use the trick of  capturing an explicit lifetime object into the lambda<\/a> to keep the parent object alive for the duration of the lambda.<\/p>\n
The second lambda is the one that captures nothing, and is therefore suitable for running as a fire-and-forget coroutine. It accepts the first lambda as its formal parameter, and since formal parameters are part of the frame, this keeps that copy alive for the duration of the task. We then invoke that first lambda with a co_await<\/code> so that the second lambda’s task will not complete until the first lambda’s task is finished. This keeps the first lambda alive for the duration of the task.<\/p>\n
Finally, we invoke the second lambda, with the first lambda as its parameter, to set things into motion.<\/p>\n
The rest of the work is fine-tuning.<\/p>\n
We pass the first lambda by value, but that is a bit wasteful because the first lambda isn’t used any more once it is passed to the second lambda. Let’s move it rather than copying. Moving also allows the first lambda to capture move-only objects, like RAII types such as std::unique_ptr<\/code>.<\/p>\n
void MyClass::MyEventHandler(int a, int b)\r\n{\r\n  auto lambda1 =\r\n   [=, lifetime = this->shared_from_this()]()\r\n   -> Concurrency::task<void>\r\n  {\r\n   GetReady(a);\r\n   co_await GetSetAsync(b);\r\n   Go(a, b);\r\n  };\r\n\r\n  auto lambda2 = [](auto lambda1)\r\n   -> Concurrency::task<void>\r\n  {\r\n   co_await lambda1();\r\n  };\r\n\r\n  lambda2(std::move(lambda1)<\/span>);\r\n}\r\n<\/pre>\n
But we can get the same effect as an explicit move by simply passing the second lambda inline, which creates an rvalue reference.<\/p>\n
void MyClass::MyEventHandler(int a, int b)\r\n{\r\n  auto lambda2 = [](auto lambda1)\r\n   -> Concurrency::task<void>\r\n  {\r\n   co_await lambda1();\r\n  };\r\n\r\n  lambda2([=, lifetime = this->shared_from_this()]()\r\n   -> Concurrency::task<void>\r\n  {\r\n   GetReady(a);\r\n   co_await GetSetAsync(b);\r\n   Go(a, b);\r\n  }<\/span>);\r\n}\r\n<\/pre>\n
And then you can go all the way and make lambda2<\/code> an immediately-invoked lambda.<\/p>\n
void MyClass::MyEventHandler(int a, int b)\r\n{\r\n  [](auto lambda1)\r\n   -> Concurrency::task<void>\r\n  {\r\n   co_await lambda1();\r\n  }([=, lifetime = this->shared_from_this()]()\r\n   -> Concurrency::task<void>\r\n  {\r\n   GetReady(a);\r\n   co_await GetSetAsync(b);\r\n   Go(a, b);\r\n  }<\/span>);\r\n}\r\n<\/pre>\n
Next time, we’ll see what we can do to reduce the boilerplate needed to carry out this pattern.<\/p>\n","protected":false},"excerpt":{"rendered":"
There are two types of lambdas you have to write, so why not write two lambdas?<\/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-100725","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
There are two types of lambdas you have to write, so why not write two lambdas?<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/100725","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=100725"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/100725\/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=100725"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=100725"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=100725"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}