Notify the completion handler through the handler's associated executor #213
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 8 commits
February 2, 2024 15:30
…s when using yield context
…the same exector that is used to launch the async function is used to notify the completion handler.
…on handler and dispatch the handler against the associated executor when it is completed. According to the rules for asynchronous operations, the outstanding work needs to be tracked against the handler's associated executor until the asynchronous operation is complete. Dispatch the completion handler through the executor, using the associated allocator and if there is no allocator use the recycled allocator by default
The boost::asio::bind_allocater only introduced in Boost 1.79. Only support the bind_allocater in Boost >= 1.79
|
Thank you for the PR. I was going to squash and merge your change but the Mac builds are failing. It looks like it's unrelated but would you mind fixing this first... it looks like it just complaining about a missing header for "current_function". |
added 9 commits
February 27, 2024 08:51
When passing a azmq::message to the azmq::async_receive() function a new azmq::message is created by the receive_buffer_op_base function call instead of using the passed in azmq::buffer. Once the async operation has completed the data does not get stored in the passed in azmq::message since it was stored in the newly created object and lost once the function call has been completed. Store the reference to the azmq::message to make sure that the correct object is used when receiving the message. Since the object is valid while calling the async function it should be fine to create the object with a reference to the original object and once the operation has been completed the object will still be valid.
This reverts commit 91b638d.
When passing a azmq::message to the azmq::async_receive() function a new azmq::message is created by the receive_buffer_op_base function call instead of using the passed in azmq::buffer. Once the async operation has completed the data does not get stored in the passed in azmq::message since it was stored in the newly created object and lost once the function call has been completed. Store the reference to the azmq::message to make sure that the correct object is used when receiving the message. When an azmq::message is passed to the receive_buffer_op_base, store the reference to the message and pass it along when receiving the information from the socket. Any other buffer type will still work the same it is just for the azmq::message type that this needs to be fixed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Added test case and solution for fix #212 .
Ensure that after the completion handler of the async operation, the same thread is still used.
After the completion handler has been completed dispatch the completion handler through the executor of the handler and using the associated allocator of the handler. The handler is moved since it is pretty safe to say that the
do_complete()function will be the last function called on the object that uses the handler.Solution based on https://github.com/chriskohlhoff/asio/blob/master/asio/src/examples/cpp14/operations/callback_wrapper.cpp that implements a custom asio operation to show how this is done.
The
boost::asio::bind_allocatorwas only added in Boost version 1.79 and I am not entirely sure howbind_allocatorworks before Boost version 1.79. Not sure how to handle this. I have left out thebind_allocatorlogic for any boost version < 1.79.