5 ms·

I'm learning rust and tokio vs async-std confuses me: if I have a library that uses tokio (e.g. tonic grpc), can I use a library that uses async-std and mix cal

I'm learning rust and tokio vs async-std confuses me: if I have a library that uses tokio (e.g. tonic grpc), can I use a library that uses async-std and mix calls to functions of those two libraries in the same function?

wokwokwok 6y ago
No. There’s no clean async abstraction later; once you pick a side, you’re stuck with crates that support it. Some popular crates let you pick using flags which one you want when you add them... but, tldr: no. It’s not ideal, but it’s very flexible. Given they weren’t sure exactly what the async runtime should look like, and the strong backwards compatibility promise, they opted for “get something people can use for now”. ...of course, the python packaging story shows this is a stupid idea in the long run, and I believe the plan is to consolidate into a single “std” async runtime eventually. ...but for now, in your situation, you’re basically screwed I’m afraid. Fork the crate and migrate it yourself is probably the only real solution. The downside is that doing that usually unearths dependencies that are also using the wrong runtime, etc. For now: Pick one, stick with it.
- swsieber 6y ago
  I think smoke is trying to be that abstraction layer? I know it makes it easy to swap out the runtime.
  - Matthias247 6y ago
    The issue with abstraction layers is typically that they can only offer the minimal amount of common functionality - which is often not good enough. They also have the tendancy to get outdated and non-maintained, since most users will just go for a runtime directly.
    - dathinab 6y ago
      > - which is often not good enough. Except that it mostly should be good enough. async-std tried to mirror rust's libstd, and tokio adapted it. Similar the global `spawn` and the value returned from it work kinda the same +- some naming differences. Even the `LocalExecutor`/`LocalSet` can be abstracted over to erase their differences. That also true for all simple usages of timout. The remaining differences are: - different internal implementation details - naming differences which are not that easy to abstract away - some detail about time/timeout handling I forgot which for many use-cases doesn't matter - the AsyncRead/AsyncWrite traits but this is going to get into std so this will go away soon - some "advanced" features like the fact that tokio overlaps the non-blocking executor thread pool with a blocking worker thread pool, but that in many case not a very important feature. - some differences in e.g. how to specify the number executor threads etc. Most other differences are "old legacy left overs" from the pre-async/await futures time periode. So while a generic in-language abstraction likely won't happen anytime soone one which uses feature flags and re-exports as basis should be very doable in the close future. (I don't know how good the mentioned one is.)
- xfer 6y ago
  Same thing happened in Ocaml land w.r.t. async vs lwt. Not sure what the current situation is but people had to abstract their libraries and do 2 implementations to support them.
- Matthias247 6y ago
  That's not fully correct. A lot of futures will work independent of the runtime. E.g. all the sync primitives/channels/etc from all sources (futures-rs/tokio/async-std/futures-intrusive/etc) will work with all runtimes. Then a lot of objects which require a runtime (e.g. an async socket) might still work on a foreign runtime as long as the original runtime is running. E.g. I think you can use async-std sockets from inside tokio, as long as the async-std runtime is also running in the background. Same is true for the other direction to a certain extent, but it's a bit more complicated to set up. So overall you will need to understand how the runtimes work and if particular pieces can be mixed and matched. If you don't want to invest in that knowledge => stay on one side. And before someone starts to blame the Rust ecosystem for that: It's not really different in any other environment. You can't easily mix and match GTK, QT, libuv and boost asio eventloops. It's event a lot harder than trying to combine Rusts async types.
  - pjmlp 6y ago
    You can mix and match C++20 co-routines, C#/F#/VB co-routines, Kotlin co-routines, that is the whole idea.
    - Matthias247 6y ago
      I can probably. I guess a few prinicpal/staff engineers can too. But doing cross FFI async function invocations and trying to unify runtimes in that fashion is not a thing that people usually do. And it still wouldn't allow you to call QT socket APIs and Netty socket APIs from the same thread.
      - pjmlp 6y ago
        You missed the point, the languages I mentioned have it as relevant enough to have the async runtime as part of the standard library, instead of leaving it to 3rd parties.
        Matthias247 6y ago
        C++ coroutines are not more „part of the standard library“ than rusts async support. One might say it might be less, since they arrived so late in c++ lifetime and more Production libraries have been built without them und mind. And again, they don’t make GTK and Qt and boost Asia eventloops interoperable. Even if you implement co_await support for each of them individually
dathinab 6y ago
No, through in some cases yes. There is also a `tokio02` feature which let's you run tokio inside of async-std. The problems are: - The global `spawn` method need to know on which executor to spwan thinks, the ones for tokio look for a tokio executor the ones for `async-std` for a async std one. - The async-io implementations might require to be run in the executor they are shipped with. - Some combinators shipped with some runtimes also need to be run in that runtime. This is a bit annoying. I believe everyone involved would have preferred a single general purpose runtime, but to all kinds of reasons this didn't work out. The original plan was to provide generic interfaces in the futures library so that most code (including things like grpc) can be independent of the runtime. But people couldn't agree on a common interface. The main problem was around how to do the `AsyncIo` trait and timers. Since the introduction of async/await the runtimes have converged a lot more in their external interfaces, and there are plan to put `AsyncRead`/`AsyncWrite` traits into std. After this the divergence problem might maybe be fixed slowly. --- To provide some more information about the problem: Basically a executor consists of three parts: 1. The thing driving/running/polling futures. 2. A reactor handling the async io details. 3. Something to handle things lie `Delay`/`Timeout`. For the first point the problem is a missing standardized way to `spawn` new independent futures and another way to do so locally (`LocalExecutor`/`LocalSet`). For the second point it's not so likely that things will converge but we could agree on a way to have multiple `Reactors` running in parallel or similar in ways which should "just work" without to much overhead. For the third point people currently can't agree one specific implementation as far as I remember once they do we might at least have a generic timer interface. Anyway by now most of the (new) external APIs of both async-std and tokio now mirror std (tokio copied that once it turned out it was a good idea). This also means that most implementations can be made to work with any executor by having a feature for any of the executors and then depending on the feature import different things, for most parts most of the code will just work by importing think from async-std instead of think from tokio.

wokwokwok 6y ago

No. There’s no clean async abstraction later; once you pick a side, you’re stuck with crates that support it. Some popular crates let you pick using flags which one you want when you add them... but, tldr: no. It’s not ideal, but it’s very flexible. Given they weren’t sure exactly what the async runtime should look like, and the strong backwards compatibility promise, they opted for “get something people can use for now”. ...of course, the python packaging story shows this is a stupid idea in the long run, and I believe the plan is to consolidate into a single “std” async runtime eventually. ...but for now, in your situation, you’re basically screwed I’m afraid. Fork the crate and migrate it yourself is probably the only real solution. The downside is that doing that usually unearths dependencies that are also using the wrong runtime, etc. For now: Pick one, stick with it.

swsieber 6y ago
I think smoke is trying to be that abstraction layer? I know it makes it easy to swap out the runtime.
- Matthias247 6y ago
  The issue with abstraction layers is typically that they can only offer the minimal amount of common functionality - which is often not good enough. They also have the tendancy to get outdated and non-maintained, since most users will just go for a runtime directly.
  - dathinab 6y ago
    > - which is often not good enough. Except that it mostly should be good enough. async-std tried to mirror rust's libstd, and tokio adapted it. Similar the global `spawn` and the value returned from it work kinda the same +- some naming differences. Even the `LocalExecutor`/`LocalSet` can be abstracted over to erase their differences. That also true for all simple usages of timout. The remaining differences are: - different internal implementation details - naming differences which are not that easy to abstract away - some detail about time/timeout handling I forgot which for many use-cases doesn't matter - the AsyncRead/AsyncWrite traits but this is going to get into std so this will go away soon - some "advanced" features like the fact that tokio overlaps the non-blocking executor thread pool with a blocking worker thread pool, but that in many case not a very important feature. - some differences in e.g. how to specify the number executor threads etc. Most other differences are "old legacy left overs" from the pre-async/await futures time periode. So while a generic in-language abstraction likely won't happen anytime soone one which uses feature flags and re-exports as basis should be very doable in the close future. (I don't know how good the mentioned one is.)
xfer 6y ago
Same thing happened in Ocaml land w.r.t. async vs lwt. Not sure what the current situation is but people had to abstract their libraries and do 2 implementations to support them.
Matthias247 6y ago
That's not fully correct. A lot of futures will work independent of the runtime. E.g. all the sync primitives/channels/etc from all sources (futures-rs/tokio/async-std/futures-intrusive/etc) will work with all runtimes. Then a lot of objects which require a runtime (e.g. an async socket) might still work on a foreign runtime as long as the original runtime is running. E.g. I think you can use async-std sockets from inside tokio, as long as the async-std runtime is also running in the background. Same is true for the other direction to a certain extent, but it's a bit more complicated to set up. So overall you will need to understand how the runtimes work and if particular pieces can be mixed and matched. If you don't want to invest in that knowledge => stay on one side. And before someone starts to blame the Rust ecosystem for that: It's not really different in any other environment. You can't easily mix and match GTK, QT, libuv and boost asio eventloops. It's event a lot harder than trying to combine Rusts async types.
- pjmlp 6y ago
  You can mix and match C++20 co-routines, C#/F#/VB co-routines, Kotlin co-routines, that is the whole idea.
  - Matthias247 6y ago
    I can probably. I guess a few prinicpal/staff engineers can too. But doing cross FFI async function invocations and trying to unify runtimes in that fashion is not a thing that people usually do. And it still wouldn't allow you to call QT socket APIs and Netty socket APIs from the same thread.
    - pjmlp 6y ago
      You missed the point, the languages I mentioned have it as relevant enough to have the async runtime as part of the standard library, instead of leaving it to 3rd parties.
      - Matthias247 6y ago
        C++ coroutines are not more „part of the standard library“ than rusts async support. One might say it might be less, since they arrived so late in c++ lifetime and more Production libraries have been built without them und mind. And again, they don’t make GTK and Qt and boost Asia eventloops interoperable. Even if you implement co_await support for each of them individually

dathinab 6y ago

No, through in some cases yes. There is also a `tokio02` feature which let's you run tokio inside of async-std. The problems are: - The global `spawn` method need to know on which executor to spwan thinks, the ones for tokio look for a tokio executor the ones for `async-std` for a async std one. - The async-io implementations might require to be run in the executor they are shipped with. - Some combinators shipped with some runtimes also need to be run in that runtime. This is a bit annoying. I believe everyone involved would have preferred a single general purpose runtime, but to all kinds of reasons this didn't work out. The original plan was to provide generic interfaces in the futures library so that most code (including things like grpc) can be independent of the runtime. But people couldn't agree on a common interface. The main problem was around how to do the `AsyncIo` trait and timers. Since the introduction of async/await the runtimes have converged a lot more in their external interfaces, and there are plan to put `AsyncRead`/`AsyncWrite` traits into std. After this the divergence problem might maybe be fixed slowly. --- To provide some more information about the problem: Basically a executor consists of three parts: 1. The thing driving/running/polling futures. 2. A reactor handling the async io details. 3. Something to handle things lie `Delay`/`Timeout`. For the first point the problem is a missing standardized way to `spawn` new independent futures and another way to do so locally (`LocalExecutor`/`LocalSet`). For the second point it's not so likely that things will converge but we could agree on a way to have multiple `Reactors` running in parallel or similar in ways which should "just work" without to much overhead. For the third point people currently can't agree one specific implementation as far as I remember once they do we might at least have a generic timer interface. Anyway by now most of the (new) external APIs of both async-std and tokio now mirror std (tokio copied that once it turned out it was a good idea). This also means that most implementations can be made to work with any executor by having a feature for any of the executors and then depending on the feature import different things, for most parts most of the code will just work by importing think from async-std instead of think from tokio.