slowtec/tokio-modbus

Remove "sync" feature(s)

uklotzde opened this issue · 4 comments

Bundling an opinionated synchronous API wrapper around the native, asynchronous API is unfortunate and wrong. It only causes trouble and misunderstandings. I recommend to remove it before releasing version 1.0.

If users need synchronous communication they should use a different library.

If users need synchronous communication they should use a different library.

Do you have one to suggest?

If users need synchronous communication they should use a different library.

Do you have one to suggest?

Unfortunately not.

Re-implementing the sync client(s) by reusing common parts from frame and codec but without the unnecessary Frankenstein-ean loop through the Tokio runtime would be the path forward.

I was starting to build up a library on top of this crate and started to use traits. The code started getting more complex than it needed to be so I tried out the sync version of the library only to discover its also creating creating and managing its own runtimes.

Maybe theres an alternate approach here where a runtime handle could be passed into the sync of this library, or one could be discovered.

This is the error I was running into when trying to connect:

thread 'main' panicked at ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-modbus-0.13.1/src/client/sync/mod.rs:42:13:
Cannot start a runtime from within a runtime. This happens because a function (like `block_on`) attempted to block the current thread while the thread is being used to drive asynchronous tasks.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

My goal here was to asynchronously query multiple servers and for simplicity with the traits I was going to use sync inside each thread to query the one device.