On Thu, 13 Jun 2024 at 12:18, Stefano Mora via Boost
Hello, hope to have found a solution.
The problem seems to be caused to a "random" readCompleted() callback function recalled with error=0 and byteTransferred=0 - while Wireshark shows me that the packet was received! At the beginning I only exit from the function but the TimeoutExpired arrived. I corrected the procedure adding the rearm of the async read in case of error==0 and bytes==0. Now I'm able to recover the packet and go on!
I don't know why the callback function is called with bytes=0, but that's the way ..
In Asio, every time you call an async function, you will eventually get a completion callback. So every time you attempt a read, two callbacks will always get generated, one for the timer, one for the read operation. This is true even if one of the operations gets cancelled - the callback will happen to contain an "asio::error::operation_aborted" error, but will get called. In case of timeout, your code is only dispatching the event loop (calling run_one) until one of the callbacks gets called, then throws. The other callback still sits there, waiting for it to be dispatched. The next run_one, it will get called, even if it belongs to the previous operation. This is the behavior you're seeing. What your code is trying to do is best modelled in Asio as a parallel group. This is an experimental feature, but should work fine for you. I've rewritten your TimeoutSerial class using parallel_group. You can find it in this gist: https://gist.github.com/anarthal/4e6ac7fdffc6af4bc14c9d64060d534b I haven't tried it on a real serial port, but it should do the job. Regards, Ruben.