{"id":109721,"date":"2024-05-02T07:00:00","date_gmt":"2024-05-02T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=109721"},"modified":"2024-05-02T11:09:28","modified_gmt":"2024-05-02T18:09:28","slug":"20240502-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20240502-00\/?p=109721","title":{"rendered":"Awaiting a set of handles with a timeout, part 3: Going beyond two"},"content":{"rendered":"

Last time, we figured out how to await two handles with a common timeout<\/a>. Armed with what we learned from that ordeal, we can try to generalize it to an arbitrary number of handles.<\/p>\n

Our first attempt might go like this:<\/p>\n

template<typename Iter>\r\nwil::task<std::vector<bool>>\r\n    resume_on_all_signaled(Iter first, iter last,\r\n        winrt::Windows::Foundation::TimeSpan timeout = {})\r\n{\r\n    using BoolOp = winrt::Windows::Foundation::IAsyncOperation<bool>;\r\n\r\n    std::vector<BoolOp> ops;\r\n    std::transform(first, last, std::back_inserter(ops),\r\n        [&](HANDLE handle) {\r\n        return resume_on_one_signal(handle, timeout);\r\n    });\r\n\r\n    std::vector<bool> results;\r\n    for (auto&& op : ops) {\r\n        results.push_back(co_await winrt::resume_agile(op));\r\n    }\r\n\r\n    co_return std::move(results);\r\n}\r\n<\/pre>\n
The first step is to take the incoming handles and convert them to async operations, which we gather in a vector.<\/p>\n
Next, we await each of the awaiters and push the result onto a results vector.<\/p>\n
Finally, we return the results.<\/p>\n
Now, one of the really annoying things happening here is that we are using vector<bool><\/code>.  As I noted some time ago<\/a>, this specialization represents a packed bit array. This has made a lot of people very angry and  has been widely regarded<\/a> as a  bad move<\/a>.<\/p>\n
So let’s use a C-style array of bool<\/code> instead. C++\/WinRT comes with one already, known as winrt::com_array<\/code>. We’ll use that.<\/p>\n
template<typename Iter>\r\nwil::task<winrt::com_array<bool><\/span>>\r\n    resume_on_all_signaled(Iter first, iter last,\r\n        winrt::Windows::Foundation::TimeSpan timeout = {})\r\n{\r\n    using BoolOp = winrt::Windows::Foundation::IAsyncOperation<bool>;\r\n\r\n    std::vector<BoolOp> ops;\r\n\r\n    std::transform(first, last, std::back_inserter(ops),\r\n        [&](HANDLE handle) {\r\n        return resume_on_one_signal(handle, timeout);\r\n    });\r\n\r\n    if (ops.size() > ~0U \/ sizeof(bool)) {                   <\/span>\r\n      throw std::bad_alloc();                                <\/span>\r\n    }                                                        <\/span>\r\n    auto size = static_cast<uint32_t>(ops.size());           <\/span>\r\n    auto results = winrt::com_array{ size };                 <\/span>\r\n    for (auto index = 0U; index < size; ++index) {           <\/span>\r\n        results[index] =                                     <\/span>\r\n               co_await winrt::resume_agile(awaiters[index]);<\/span>\r\n    }                                                        <\/span>\r\n\r\n    co_return std::move(results);\r\n}\r\n<\/pre>\n
There is a serious issue: We behave erratically if an exception is thrown from co_await<\/code>.<\/p>\n
An exception is possible because the awaiter returned by resume_on_signal<\/code> will throw an exception if it cannot set up the threadpool wait. In that case, the state of the handles is indeterminate: Some of them may have been successfully waited, and others may not have been, and you don’t know which were and weren’t waited because the exception prevented you from receiving the results.<\/p>\n
Knowing which ones were awaited is important if any of the things you are waiting for are consumable, such as semaphores or auto-reset events.<\/p>\n
We’ll continue our investigation next time.<\/p>\n","protected":false},"excerpt":{"rendered":"
Generalizing what we learned last time.<\/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-109721","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Generalizing what we learned last time.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/109721","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=109721"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/109721\/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=109721"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=109721"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=109721"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}