4 ms·

> So overall you will need to understand how the runtimes work and if particular pieces can be mixed and matched... Hm... really? I was under the impression t

> So overall you will need to understand how the runtimes work and if particular pieces can be mixed and matched... Hm... really? I was under the impression that it was more correct to say that mixing runtimes is undefined behaviour? It may work, but just like mutable aliasing using unsafe may not cause memory corruption; it just happens to work in the current implementation, on the current platform, on the current version of rust. There is no guarantee it will continue to work in the future. Maybe I misunderstood, but I thought it was a lot more complicated than just starting multiple events loops and you’re fine.

Matthias247 6y ago
Yes - really! It would be undefined behavior if the runtime doesn't make any promises about it. But some do make the promises that it will work. I think both async-std and tokio make sure IO related futures work from tasks that are driven by a different runtime - otherwise stuff like `future::executor::block_on(task)` would also not work, and neither would the blocking wrappers around some of the HTTP clients. However the IO objects might need to be initialized within a certain context (e.g. some TLS variables need to be set for tokio). And there might be a few different things one need watch out for. E.g. if you stop the background runtime things might get weird - however this e.g. can't happen with async-std since the background runtime will never shut down.
- wokwokwok 6y ago
  I couldn’t find any docs on this, got a link by any chance? Specifically where tokio commits to working with other runtimes.
  - stjepang 6y ago
    https://docs.rs/async-compat https://docs.rs/async-compat
    - wokwokwok 6y ago
      This seems unrelated. Some arbitrary 3rd party wrapper does not make any guarantees about the runtimes it wraps. This is just more “happens to work at the moment”.

Matthias247 6y ago

Yes - really! It would be undefined behavior if the runtime doesn't make any promises about it. But some do make the promises that it will work. I think both async-std and tokio make sure IO related futures work from tasks that are driven by a different runtime - otherwise stuff like `future::executor::block_on(task)` would also not work, and neither would the blocking wrappers around some of the HTTP clients. However the IO objects might need to be initialized within a certain context (e.g. some TLS variables need to be set for tokio). And there might be a few different things one need watch out for. E.g. if you stop the background runtime things might get weird - however this e.g. can't happen with async-std since the background runtime will never shut down.

wokwokwok 6y ago
I couldn’t find any docs on this, got a link by any chance? Specifically where tokio commits to working with other runtimes.
- stjepang 6y ago
  https://docs.rs/async-compat https://docs.rs/async-compat
  - wokwokwok 6y ago
    This seems unrelated. Some arbitrary 3rd party wrapper does not make any guarantees about the runtimes it wraps. This is just more “happens to work at the moment”.