Tokio support

[NathanSWard]

Describe the feature

It's unfortunate in the Rust ecosystem that we have multiple different async runtime w/ different APIs.
However, tokio is by far the most popular, widely used, and tested runtime compared to async_std, smol, etc...

It appears that Zenoh has locked itself currently into using async_std which will likely prevent adoption from Rust devs who have already chosen tokio and don't wish to introduce a new runtime just for Zenoh.

At my company we are considering using Zenoh for our robot fleet communication - however, we already have a majority of our code supporting tokio and needing to shoehorn async_std will likely prove more difficult than the benefits we will be receiving.

Is it possible to add support for tokio? Ideally this would be behind a feature flag so devs could choose which runtime they want, but not supporting tokio seems like a huge mistake when it comes to adoption of Zenoh.

[YuanYuYuan]

Hi @NathanSWard! It's on our plan. We're surviving the change of asynchronous runtime to tokio in this pull request.

[NathanSWard]

Awesome, this is great to hear @YuanYuYuan !
If this needs any assistance - please let me know how I could help!

[marvin-hansen]

Fully support this feature.

I had to freeze zenoh adoption for my company because it does not support tokio yet. However, that would change the moment Tokio support is available as I am not exactly content with the alternative.

As far as I understand the async situation, you can configure the async runtime behind feature flag and then users decides which one they want to use. See this project for example, that already supports both, std-asynd and tokio

https://github.com/zeromq/zmq.rs/blob/master/Cargo.toml

Also, I would be willing to do some testing.

[YuanYuYuan]

Hi @marvin-hansen, thanks for your information! Supporting both runtimes wouldn't be our priority for the time being. The runtime switch problem in Zenoh library is from async-global-executor to Tokio runtime. Although it's able to change async runtime on async-global-executor (like the zmq.rs does but more), we found that the Tokio one still relies on async-std. We want to avoid this since async-std has been stale for a while.

Furthermore, we have a refactor on async usage in our code base while porting to Tokio. The idea is different from the current async-global-executor version. In the next release, our goal is to keep the performance, have more runtime controllability, and embrace the Tokio ecosystem.

[marvin-hansen]

Thanks,

That has settled the case.

Eventually I've switched my messaging to Fluvio because it fully supports Tokio and is production ready.

https://www.fluvio.io

It seems to me that this project has quite a bit of groundwork to do before becoming viable.

Nevermind.

[YuanYuYuan]

Has been completed via #830 and #566.
@Mallets do you mind closing this issue and changing its status to Done?