Asio: can a asyn_write handler came after a asyn_read handler?
Asio 1.88 im currently trying to understand a TCP server/client implementation at a new customer project the statemachine of the user code bases on the fact that a handler of an async_write needs to always comes before the handler of an async_read i don't think that is guaranteed, is it? this is the redcuded scenario: an async_read wait for a single reply from the connected sever a single async_write is done that make the server reply a single paket in the waiting aysnc_read is it possible that the async_write handler comes after the async_read handler? i had a look at the Asio implementation for Windows and it seems that the write handler will be come before - but im not that deep in the implementation
On Mon, Jul 21, 2025 at 1:55 PM Dennis Luehring via Boost <boost@lists.boost.org> wrote:
is it possible that the async_write handler comes after the async_read handler?
Asio does not provide any guarantees in this regard. The behavior depends entirely on the implementation of the network stack and the event notification mechanism used by the operating system. For example, on Linux with the epoll API:
If more than maxevents file descriptors are ready when epoll_wait() is called, then successive epoll_wait() calls will round robin through the set of ready file descriptors. This behavior helps avoid starvation scenarios, where a process fails to notice that additional file descriptors are ready because it focuses on a set of file descriptors that are already known to be ready.
This clearly violates your requirements. Even if we assume no reordering occurs in the network stack.
On Mon, Jul 21, 2025 at 3:58 PM Mohammad Nejati [ashtum] <ashtumashtum@gmail.com> wrote:
This clearly violates your requirements. Even if we assume no reordering occurs in the network stack.
I should make a correction here: in the case of epoll, since it only notifies that the socket is write-ready and the actual write operation happens inside the application, we can be sure that the completion handler for the write operation is queued before the read operation. However, in the case of io_uring or Windows IOCP, the event is received only after the actual write is complete, so reordering can become an issue.
Am 21.07.2025 um 15:35 schrieb Mohammad Nejati [ashtum] via Boost:
I should make a correction here: in the case of epoll, since it only notifies that the socket is write-ready and the actual write operation happens inside the application, we can be sure that the completion handler for the write operation is queued before the read operation. However, in the case of io_uring or Windows IOCP, the event is received only after the actual write is complete, so reordering can become an issue.
that makes fully sense as the problem with the wrong statemachine assumption seem to only happen on Windows but not on the Linux(wich uses ASIO/epoll) tests systems thanks for the more inside information Dennis
On Mon, 21 Jul 2025 at 12:26, Dennis Luehring via Boost < boost@lists.boost.org> wrote:
the statemachine of the user code bases on the fact that a handler of an async_write needs to always comes before the handler of an async_read
i don't think that is guaranteed, is it?
<snip>
is it possible that the async_write handler comes after the async_read handler?
Yes, that used to be a bug in Boost.Redis. Quoting the Changelog entry [1] Under load and on low-latency networks it is possible to start receiving
responses before the write operation is completed and while the request is still marked as staged and not written. This messes up with the heuristics that classifies responses as unsolicited or not.
[1] https://github.com/boostorg/redis/blob/76129bbcb8373f23d37877fccededb288690e...
Am 21.07.2025 um 21:48 schrieb Marcelo Zimbres Silva via Boost:
Yes, that used to be a bug in Boost.Redis. Quoting the Changelog entry [1]
Under load and on low-latency networks it is possible to start receiving
responses before the write operation is completed and while the request is still marked as staged and not written. This messes up with the heuristics that classifies responses as unsolicited or not.
thank you for your response - makes it much easier to sell my finding to the other devs :)
participants (3)
-
Dennis Luehring -
Marcelo Zimbres Silva -
Mohammad Nejati [ashtum]