|
Boost : |
From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2024-06-13 18:15:50
On Thu, 13 Jun 2024 at 12:18, Stefano Mora via Boost
<boost_at_[hidden]> wrote:
>
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk