{"id":109725,"date":"2024-05-03T07:00:00","date_gmt":"2024-05-03T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=109725"},"modified":"2024-05-03T08:31:50","modified_gmt":"2024-05-03T15:31:50","slug":"20240503-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20240503-00\/?p=109725","title":{"rendered":"Awaiting a set of handles with a timeout, part 4: Building our own awaiter"},"content":{"rendered":"

Last time, we figured out how to await an arbitrary number of handles with a common timeout<\/a>. But we found that there were two fundamental problems: The awaiter might not be movable, and we don’t want to throw an exception after some of the handles have been signaled (because that causes us to lose track of them).<\/p>\n

Since we don’t control the awaiter used by resume_on_signal<\/code>, we’ll have to switch to something we do control.<\/p>\n

We’ll write our own awaiter.<\/p>\n

Fortunately, writing an awaiter is easier than writing a coroutine promise. We just need to implement the three awaiter methods: await_ready<\/code>, await_suspend<\/code>, and await_resume<\/code>.<\/p>\n

In order to avoid the problem of throwing an exception partway through, we need to make sure we set up everything that could possibly throw an exception before we start waiting on any of the handles.<\/p>\n

Here’s our first attempt. Let’s start with the simple case that we are given a counted array of HANDLE<\/code>s. Our function prototype will be this:<\/p>\n

auto resume_on_all_signaled(HANDLE* handles, uint32_t size,\r\n    std::optional<winrt::Windows::Foundation::TimeSpan> timeout\r\n        = std::nullopt);\r\n<\/pre>\n
I changed the timeout<\/code> parameter to an optional TimeSpan<\/code>, where an empty value means that there is no timeout. This avoids problems in the original code where 0 meant “no timeout (wait indefinitely)”, but a value of zero, or even a negative value, could be generated by mistake, say because the deadline has been reached or has already been passed. Making it an explicitly optional parameter avoids this edge case where a computed timeout happens to match the sentinel value. It also means that you will be able to pass a timeout of zero to probe the handles without waiting.<\/p>\n
We start with this guy:<\/p>\n
struct resume_all_state\r\n{\r\n    struct resume_all_awaiter* m_parent;\r\n    HANDLE m_handle;\r\n    bool* m_result;\r\n    wil::unique_threadpool_wait_nowait m_wait;\r\n    };\r\n<\/pre>\n
The resume_all_state<\/code> holds the information we need about each handle. It holds a pointer to the awaiter (to be defined below), the handle we are waiting for, where we should record the result of the handle wait, and the threadpool wait that will notify us when the handle is signaled (or the timeout elapses).<\/p>\n
struct resume_all_awaiter\r\n{\r\n<\/pre>\n
To save ourselves some typing, we’ll create a type alias.<\/p>\n
    using TimeSpan = winrt::Windows::Foundation::TimeSpan;\r\n<\/pre>\n
And then we can declare our member variables.<\/p>\n
    std::atomic<uint32_t> m_remaining;\r\n    std::vector<resume_all_state> m_states;\r\n    winrt::com_array<bool> m_results;\r\n    std::coroutine_handle<> m_resume;\r\n    std::optional<TimeSpan> m_timeout;\r\n<\/pre>\n
The awaiter keeps track of a few things.<\/p>\n