async_std support

[Demi-Marie]

quinn-proto is extremely low-level and difficult to use. quinn is much nicer to use, but depends on Tokio. Would it be possible for quinn to also support async_std via a Cargo feature?

[Ralith]

Thanks for the issue! I think the right way to approach this is to make quinn abstract over runtime, i.e. the thing providing wake-ups for I/O and timers, as cargo features can't be mutually exclusive. This might also be useful for more pure end-to-end testing. Note that quinn implements its own UdpSocket to gain access to low-level features like explicit congestion notification flags, and a good solution should avoid duplicating that code.

[Demi-Marie]

Due to async-rs/async-std#293 quinn’s UdpSocket won’t be usable on async-std, so we will need to provide an alternative. That should be doable, however.

[jean-airoldie]

From what i understand you could replace the tokio dependency with smol & futures-io:

• tokio::io::Async{Read,Write} becomes futures_io::Async{Read,Write}
• tokio-rustls becomes async-tls
• PollEventedmio::net::UdpSocket becomes smol::Asyncstd::net::UdpSocket
• tokio::time becomes either futures-timer or smol::Timer

However you would need to find a non tokio alternative for tokio_util::codec, although it wouldn't be too hard to adapt the code.

I think this should make quinn abstract over runtime.

[Ralith]

From what i understand you could replace the tokio dependency with smol & futures-io:

My understanding is that this amounts to a hidden hard dep on a smol background thread, so we'd just be trading one required runtime for another. Unless I misunderstand how smol works these days? I'd prefer to be genuinely runtime-agnostic as outlined above.

tokio::io::Async{Read,Write} becomes futures_io::Async{Read,Write}

quinn implements both of these traits for streams already; the tokio variants could be feature flagged easily enough.

However you would need to find a non tokio alternative for tokio_util::codec, although it wouldn't be too hard to adapt the code.

Indeed that's pretty trivial code, which we could easily vendor if need be.

[jean-airoldie]

Unless I misunderstand how smol works these days? I'd prefer to be genuinely runtime-agnostic as outlined above.

Right. The only real benefit is that you can run your quinn sockets in a non-tokio runtime without crashing.

[Ralith]

You can spawn a thread to run tokio in the background too (you just have to wrap the initial setup in Handle::enter), so I don't think that would buy us anything.

[Ralith]

Thanks for your interest, regardless! Hopefully this type of composability problem gets easier to address in the future.

[yvonmanzi]

Hi, @Ralith! I would like to bring up this issue once again. Any progress in this direction? We would like to use quinn in our project, which relies heavily on async-std, so any effort to make quinn runtime agnostic would be amazing. Do you have any new insights into how we can make that happen? I am happy to help with the effort but I'd definitely need help figuring out how to go about solving this.

[djc]

@yvonmanzi so far no progress has been made on this issue (that I am aware of). We'll mentor you through implementing if that's of interest to you, or otherwise I can provide commercial support if that's an option.

[yvonmanzi]

Thank you @djc for a quick response. I definitely appreciate the mentorship. I am going to start looking into various routes through which I can approach this. Any pointers, advice, etc for me to look into before I get started would go a long way.

[djc]

You could maybe look at the trust-dns crate for some examples. It has a Runtime trait that already abstracts over some of the things we would also need. Would probably useful to start with enumerating a list of tokio types and functions used and post them back here so we can review what to do for each. The hardest part is probably the custom UdpSocket, you may want to start with that.

[yvonmanzi]

Okay, thanks!

[aryan9600]

Hello @Ralith @djc we want to add QUIC support to tremor which uses async_std as an async runtime. Abstracting the runtime sounds perfect as it gives us the option of not having to use smol to interop between tokio and async_std. Is there any progress on this? I am willing to work on this (given of course, no one else is already) although I will definitely need some mentorship.

[djc]

@aryan9600 I'm not aware of any progress so far. Would be great if you can work on this, will be happy to guide you along.

[jean-airoldie]

Hello @Ralith @djc we want to add QUIC support to tremor which uses async_std as an async runtime. Abstracting the runtime sounds perfect as it gives us the option of not having to use smol to interop between tokio and async_std. Is there any progress on this? I am willing to work on this (given of course, no one else is already) although I will definitely need some mentorship.

You don't actually need to use smol to interrop. All you need is to lazy initialize a tokio::runtime::Handle and then call tokio::runtime::Handle::enter before each quinn call to tokio.

[yu-re-ka]

I have the quinn server example running with async-std, if there is still interest I could implement async-std and tokio support using two seperate feature flags.

[parazyd]

I have the quinn server example running with async-std, if there is still interest I could implement async-std and tokio support using two seperate feature flags.

This would be lovely. I can help too if needed.

[Ralith]

Fix drafted in #1364. Review from people familiar with async-std would be particularly welcome.