Skip to content

Optional Recursive Mutex in Asio Integration - #1846

Open
RobertLeahy wants to merge 3 commits into
NVIDIA:mainfrom
RobertLeahy:optional_recursive_mutex_20260214
Open

Optional Recursive Mutex in Asio Integration#1846
RobertLeahy wants to merge 3 commits into
NVIDIA:mainfrom
RobertLeahy:optional_recursive_mutex_20260214

Conversation

@RobertLeahy

Copy link
Copy Markdown
Contributor

Please do not squash.

Resolves#1781.

@copy-pr-bot

Copy link
Copy Markdown

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@ericnieblerericniebler left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

nit picks

Comment threadinclude/asioexec/completion_token.hpp Outdated
Comment threadinclude/asioexec/completion_token.hpp Outdated
Comment threadinclude/asioexec/completion_token.hpp Outdated
Comment threadinclude/asioexec/completion_token.hpp Outdated
Comment threadinclude/asioexec/completion_token.hpp Outdated
Comment threadinclude/asioexec/completion_token.hpp Outdated
Comment threadinclude/asioexec/use_sender.hpp Outdated
@ericniebler

Copy link
Copy Markdown
Collaborator

/ok to test 72c179e

@ericniebler

Copy link
Copy Markdown
Collaborator

@RobertLeahy did you see my comments? also, this PR needs a rebase.

@RobertLeahy

Copy link
Copy Markdown
ContributorAuthor

@RobertLeahy did you see my comments? also, this PR needs a rebase.

Yes, just haven't looped back to incorporating any of the feedback.

@RobertLeahy
RobertLeahyforce-pushed the optional_recursive_mutex_20260214 branch from 72c179e to 6ffbd0aCompareAugust 1, 2026 16:45
@ericniebler

Copy link
Copy Markdown
Collaborator

/ok to test 6ffbd0a

@ericniebler

Copy link
Copy Markdown
Collaborator

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.
@RobertLeahy
RobertLeahyforce-pushed the optional_recursive_mutex_20260214 branch from 6ffbd0a to 51d2dadCompareAugust 9, 2026 22:19
@ericniebler

Copy link
Copy Markdown
Collaborator

/ok to test 51d2dad

Sign up for freeto 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.

Recursive Mutex in Asio Integration Should Be Optional

2 participants

@RobertLeahy@ericniebler