When you say:

- The way it handles cancellation is not ideal - it should wait until both async operations finish before returning or throwing the relevant exception.

which operations are you referring on? Read and Write?

When you call TimeoutSerial::read, two async operations are fired in parallel: - A read operation (asio::async_read, in your case): https://github.com/fedetft/serial-port/blob/291a7997a665a52bf37d15c615679445... - A timer wait (https://github.com/fedetft/serial-port/blob/291a7997a665a52bf37d15c615679445...) The idea is that you run both in parallel, and when the first one finishes, the second one gets cancelled. However, even if you cancel an Asio async operation, its completion handler gets called (with a cancelled error code). The problem is that TimeoutSerial::read, upon timeout, is cancelling the asio::async_read operation but not waiting for the handler to be called: https://github.com/fedetft/serial-port/blob/291a7997a665a52bf37d15c615679445... This is being workarounded in these lines, but the workaround is not taking OSX into account: https://github.com/fedetft/serial-port/blob/291a7997a665a52bf37d15c615679445... Writing this cleanly requires a big refactor of the class. For a quick workaround, you can try adding this line just after the ones I linked to: if (error == boost::asio::error::operation_aborted) return; Ruben.

Hello, please I need other information about the serial port read + timeout. Referring to the TimeoutSerial class: in the read(char*,size_t) implementation I understand that it run an async read and then it wait on timer. The for loop the function waits on io.run_one(): I guess that both port and timer are under the io (io_context) control (by the constructors). It is not clear what happen in some steps:at the beginning I only try to read something (just eventually to empty the queue) with a 100ms timeout. Then I sent 2 chars (ESC ESC) to check the presence of the device. My log is: [WriteCommand] Write nbytes: 0 [WaitForResponse] ms 100 [WaitForResponse] or pattern: '' RX .. [Tos] async_read_until .. [ToSerial][timeoutExpired] error system:0 [Tos][read] exit from run_one result: 3 = resultTimeoutExpired [waitForResponse] catch TIMEOUT dt:0 Send ESC ESC .. [WriteCommand] Write nbytes: 2 [WaitForResponse] ms 2000 [WaitForResponse] or pattern: '

' RX .. [Tos] async_read_until ..

[ToSerial][readCompleted] - error: system:995 - bytes: 0 [Tos][read] exit from run_one result: 0 [ToSerial][readCompleted] - error: system:0 - bytes: 210 [readCompleted] success! [Tos][read] exit from run_one result: 1 RX [207] : '[?25l******************************** ' [TP][WaitForResponse] Edn wait End ESC ESC !! My question is: - on the first read correctly the timeout handler is recalled, it set the resultTimeoutExpired state and exits. The run_one() exits with value 3 and the switch selects the case where it cancels the port and throws the timeout_exception. Why the readCompleted function (aborted 995) is recalled more later, after the ESC_ESC buffer is sent and another async_read_until is rearmed? Anyway the reply is received .. Thanks

On Thu, 13 Jun 2024 at 12:18, Stefano Mora via Boost 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.