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.