Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove "sync" feature(s) #145

Open
uklotzde opened this issue Feb 5, 2023 · 4 comments
Open

Remove "sync" feature(s) #145

uklotzde opened this issue Feb 5, 2023 · 4 comments
Milestone

Comments

@uklotzde
Copy link
Member

uklotzde commented Feb 5, 2023

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.

@vfiack
Copy link

vfiack commented Feb 28, 2023

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

Do you have one to suggest?

@uklotzde
Copy link
Member Author

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.

@perobertson
Copy link

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.

@theunkn0wn1
Copy link

I have downstream library code that depends on this crate.
its extremely handy to have this crate handle both and would be a breaking change if the sync interface were dropped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants