Async runtime support
Opened this issue · 6 comments
The client currently has calls to tokio::spawn for spawning async tasks. It should allow using async-std, smol, and possibly other runtimes instead of tokio.
https://github.com/GreptimeTeam/greptimedb-client-rust/blob/bc32362adf0df17a41a95bae4221d6d8f1775656/src/channel_manager.rs#L54-L56
https://github.com/GreptimeTeam/greptimedb-client-rust/blob/bc32362adf0df17a41a95bae4221d6d8f1775656/src/stream_insert.rs#L64-L67
Makes sense to me, this is an important feature 👍
I use async-std myself.
We are using tonic for grpc which is a tokio specific library. I'm afraid it's impossible to switch async runtime unless async-std ships a shim for tokio.
The rust async world is converging to tokio ecosystem tbh.
Concretely speaking, tonic's gRPC relies on hyper for HTTP/2 -- from which comes the tokio dependence, from what I see. Fortunately, the hyper maintainers have since acknowledged the need for runtime independence, so hyper 1.0, which is currently in release candidate (RC) stage, has no dependency on tokio. Instead hyper defines its own async I/O traits since hyperium/hyper#3110, which notes:
All other integration with a runtime (Tokio) has been removed
Either Tonic will fully switch to Hyper 1.0 in the future, but if not, I believe downstream libraries can use Hyper 1.0 with Tonic already (see hyperium/tonic#1307).
More broadly, libraries depending on Tokio is the reason Tokio acquires its monopoly. Yet a lack of runtime independence reduces runtime competition and stifles the future of Rust's async ecosystem. Better implementations can always be made, and there are plenty of use-cases for alternative specialized runtimes. By not promoting runtime independence, libraries advance the vicious cycle of runtime vendor lock-in. Greptimedb's rust client is part of this process. It's a tragedy of the commons.
Thank you for the information! We will revisit this issue when hyper 1.0 released with multi-runtime support.
Checked the issue you mentioned, I saw some attempts to create standard trait for async runtimes. That will be the key to resolve this situation. You cannot blame the community to converge on the single, most supported runtime if there is no standard trait to make switching runtime easier. The fragmentation of async runtimes, APIs will also weaken the quality of implementations, when the ecosystem at its early stage.
Anyway, we are 100% willing to support more runtimes if the underlying libraries provide a foundation for doing that.