|
Boost : |
From: Stefano Mora (stefano.mora_at_[hidden])
Date: 2024-06-06 15:14:02
Thanks a lot Ruben.
I changed io_context for io_service and I need only a single serial port.
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?
How can I achieve it?
Thanks!
> Il 06/06/2024 15:57 CEST Ruben Perez <rubenperez038_at_[hidden]> ha scritto:
>
>
> Try re-creating the serial port object on timeout.
>
>
> If I'm not mistaken, error code 89 on OSX means ECANCELED.
>
> From reading https://github.com/fedetft/serial-port/blob/master/2_with_timeout/TimeoutSerial.h, I'd say that the class is not handling cancellations correctly. When a timeout occurs, serial_port::cancel gets called, which in turns makes the operation complete with a ECANCELED error code (which BTW has a different number for each platform). This line is handling the case for Linux: https://github.com/fedetft/serial-port/blob/291a7997a665a52bf37d15c615679445724cf453/2_with_timeout/TimeoutSerial.cpp#L240. But it's failing to do so for OSX.
>
> https://github.com/fedetft/serial-port/blob/master/2_with_timeout/TimeoutSerial.h does several questionable things:
> - io_service name has been deprecated long ago (in favor of io_context)
> - error codes should be checked by name, and not by number (hence avoiding problems like the one you encountered)
> - If you're creating more than one serial port in your application, this creates an io_service per object, which incurs in _a lot_ of overhead.
> - The way it handles cancellation is not ideal - it should wait until both async operations finish before returning or throwing the relevant exception.
>
> You'll probably need to do some cleanup there before proceeding.
>
> If you need more help, it may be faster to ask in the #boost-asio channel in Slack: https://cpplang.slack.com/archives/C06BRML5EFK
>
> Hope it helps.
>
> Ruben.
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk