The modbus IO clients (sunspec2.modbus.modbus.ModbusClient*) all use the blocking/synchronous socket stl, which makes sense, but in some cases, we want to have async support, so that modbus network IO isn't blocking, without jumping into threading or multi-processing, and the headaches that come with that. The read/write API of the sunspec2.modbus.client.SunSpecClientDevice abstract base would need to fork into an async/sync set of read/write APIs, so it wouldn't be just a drop-in alternate IO client that is selected as a drop-in replacement. It might be a bit disruptive or require more duplication than desired, since the async would need to spread to each of the read/write methods in the classes in sunspec2.modbus.client, I believe
I'd be happy to make some contributions for this, if welcome
The modbus IO clients (
sunspec2.modbus.modbus.ModbusClient*) all use the blocking/synchronoussocketstl, which makes sense, but in some cases, we want to have async support, so that modbus network IO isn't blocking, without jumping into threading or multi-processing, and the headaches that come with that. The read/write API of thesunspec2.modbus.client.SunSpecClientDeviceabstract base would need to fork into an async/sync set of read/write APIs, so it wouldn't be just a drop-in alternate IO client that is selected as a drop-in replacement. It might be a bit disruptive or require more duplication than desired, since the async would need to spread to each of the read/write methods in the classes insunspec2.modbus.client, I believeI'd be happy to make some contributions for this, if welcome