You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tonic's builtin transport rely on tokio runtime, but with some simple tweaking, I managed to make it work with another runtime, by providing a customized hyper::rt::Executor and Connector(tower_service::Service), ... except for the timer, which is buried deeply in the channel implementation.
Proposal
Because the callsite accepts a hyper::rt::Timer naturally, I wonder if there's any chance to expose it somehow via an interface, to allow the users set it to implementations other than tokio.
P.S.
I split the feature channel into channel and channel-full, and feature guarded some of the code related to tokio. So when only channel is enabled, it's possible to use most of the builtin channel without rely on tokio(#152). Please let me know if this is something you wanted, then I can start a PR.
Feature Request
Crates
tonic
Motivation
Tonic's builtin transport rely on tokio runtime, but with some simple tweaking, I managed to make it work with another runtime, by providing a customized
hyper::rt::Executor
and Connector(tower_service::Service
), ... except for the timer, which is buried deeply in the channel implementation.Proposal
Because the callsite accepts a
hyper::rt::Timer
naturally, I wonder if there's any chance to expose it somehow via an interface, to allow the users set it to implementations other than tokio.P.S.
I split the feature
channel
intochannel
andchannel-full
, and feature guarded some of the code related to tokio. So when onlychannel
is enabled, it's possible to use most of the builtin channel without rely on tokio(#152). Please let me know if this is something you wanted, then I can start a PR.The text was updated successfully, but these errors were encountered: