Skip to content

Add support for pause & resume of thread-bound items in coroutines#621

Open
jonwis wants to merge 7 commits intomicrosoft:masterfrom
jonwis:user/jonwis/coroutine-watcher
Open

Add support for pause & resume of thread-bound items in coroutines#621
jonwis wants to merge 7 commits intomicrosoft:masterfrom
jonwis:user/jonwis/coroutine-watcher

Conversation

@jonwis
Copy link
Member

@jonwis jonwis commented Feb 24, 2026

We saw heap & stack corruptions with code like:

auto watcher = wil::ThreadFailureCallback([](wil::FailureInfo const&) { return false; });
auto q = co_await SomethingAsync();
THROW_HR_IF(E_FAIL, q != 6);

This type and types that use it are inherently thread-bound, and there's no guarantee that the continuation happens on the same thread.

Instead, this new helper lets you say:

auto watcher = wil::ThreadFailureCallback(...);
auto q = co_await wil::with_watcher(watcher, SomethingAsync());
THROW_HR_IF(E_FAIL, q != 6);

... and the awaitable will unhook the watcher on the source thread during suspend and reattach it on the continuation thread before processing exception propagation, etc.

@jonwis
Copy link
Member Author

jonwis commented Feb 25, 2026

So I'm on these:

cmake version 4.2.3
CMake suite maintained and supported by Kitware (kitware.com/cmake).

clang version 20.1.8
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\Microsoft Visual Studio\18\Professional\VC\Tools\Llvm\x64\bin

Installed just today. I can undo the change to the cmake file - I can't reproduce it building from a vs x64 build window with the scripts or with manual "cmake --preset clang ; cmake --build --preset clang-debug" ...

Comment on lines +678 to +687
// Priority tags for SFINAE-based overload resolution
struct get_awaiter_priority_fallback
{
};
struct get_awaiter_priority_free_op : get_awaiter_priority_fallback
{
};
struct get_awaiter_priority_member_op : get_awaiter_priority_free_op
{
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a wil::details::priority_tag<N> I added (moved) somewhat recently. May be better to just re-use it? Higher N gets higher priority.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, oops, it's not in the details namespace

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copilot please fix and use the standard priority_tag<> type instead

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants