Infinite retry loop with heavy CPU load about tokio-modbus

[uklotzde]

This edge case has probably not been considered back then. The loop should definitely terminate if no progress is made and recovery fails. I would prefer exiting the loop and pass control back to the client application which could handle the retry depending on the context.

[uklotzde]

I remember that we needed this recovery loop to handle spurious failures from a device that was connected via a Serial-over-USB adapter. The code is from pre-async Tokio 0.3 were recovery from errors in async code was much more complicated.

Making the library code less stateful and opinionated should be the goal. If you see a chance to simplify the code by removing this poor-man's approach for recovery from errors then don't hesitate to do it.

[ColinFinck]

I remember that we needed this recovery loop to handle spurious failures from a device that was connected via a Serial-over-USB adapter.

Recovering from spurious failures that actually happen in practice sounds like a good reason to keep this code instead of giving up immediately and passing control back to the caller.

Instead of adding a short delay, another option would be to define a maximum number of retries.
The retry boolean variable would be replaced by a counter that is incremented on every retry and reset to zero on every success. When the maximum number of retries is reached without success (e.g. 20), we could fail and pass back control to the caller. What do you think about that?

[uklotzde]

Sure, a retry limit would also be reasonable. Ideally configurable, but a constant is probably sufficient for now.

[ColinFinck]

I've implemented the retry limit in PR #186