Uh oh!
There was an error while loading. Please reload this page.
Optional Recursive Mutex in Asio Integration - #1846
Conversation
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
ericniebler
commented
Feb 14, 2026
/ok to test 72c179e |
ericniebler
commented
Feb 22, 2026
@RobertLeahy did you see my comments? also, this PR needs a rebase. |
RobertLeahy
commented
Feb 24, 2026
Yes, just haven't looped back to incorporating any of the feedback. |
72c179e to
6ffbd0aCompareericniebler
commented
Aug 9, 2026
/ok to test 6ffbd0a |
ericniebler
commented
Aug 9, 2026
Needs merge conflict resolution |
Reduces the size of a "frame" by removing the std::unique_lock member variable and making the "frame" itself the lock guard. This is the lock management method shown when presenting exec::asio::completion_token in the CppCon 2025 talk "std::execution in Asio Codebases: Adopting Senders Without a Rewrite."
For general purpose (i.e. potentially multithreaded) use the asynchronous operations which result when passing the exec::asio:: completion_token and ::use_sender completion tokens must use a recursive mutex internally. However if the user knows that no multithreaded use will occur this recursive mutex is pure overhead. Provided the exec::asio::thread_unsafe_completion_token and _use_sender completion tokens which do not make use of a recursive mutex for the aforementioned use case.
6ffbd0a to
51d2dadCompareericniebler
commented
Aug 9, 2026
/ok to test 51d2dad |
Please do not squash.
Resolves#1781.