Created asio::experimental::awaitable_specific_ptr #1496
+346
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@chriskohlhoff I am trying to bring coroutines in parity with threads somewhat, specifically, trying to replicate boost::thread_specific_ptr, but for coroutines (awaitables).
This can be hacked externally with a lot of effort, including having to create your own executor, and make sure you use it everywhere, and then use a different awaitable class and use_awaitable. But it's hacky and relies on the user to do a lot of things, and remember to do them always. It would be like if boost::thread_specific_ptr only worked if they use my_thread instead of std::thread to launch their thread.
This creates an implementation of awaitable_specific_ptr that works with coroutines, and is automatic for any awaitable, so the user doesn't have to do anything except USE awaitable_specific_ptr - it's automatic.
Given there is no real "awaitable ID" that is externally accessible to help implement this externally, this would be a large boon for being able have an equivalent of thread-specific storage (for example for use with logging contexts, etc).