Support for different executors?

[dignifiedquire]

As far as I can tell from the current code, the executor code is already pretty isolated, so I was wondering if there is interest in general to support excutors other than tokio, and if so what the plans are and/or if you are open to pull requests to do so.

Thanks

[camshaft]

Hey thanks for the interest!

You're definitely correct: all of the executor and IO functionality comes from the IO Provider. Implementing a new runtime is quite straightforward. For example, I just added support for a discrete-event simulation runtime in #1274.

What executor were you wanting to add? I think the question is where the integration would live. We really try to have a super stable public API for the s2n-quic crate and I am hesitant to add official support for a runtime that doesn't provide value for a large portion of applications.

All that being said, the IO provider doesn't have to be a part of the actual s2n-quic crate, at least not at first. It could live in a specific integration crate that applications opt into by adding it to their dependencies. The only thing that the main crate would have to do is have a way to disable the tokio dependency being included.

Thoughts?

[dignifiedquire]

You're definitely correct: all of the executor and IO functionality comes from the IO Provider. Implementing a new runtime is quite straightforward.

great :)

What executor were you wanting to add?

The main one I would need support for now is async-std, as I am considering integrating this into a library that currently supports both async-std and tokio. The more general question for me comes from wanting to make sure there is a path for potential other runtimes later down the line.

All that being said, the IO provider doesn't have to be a part of the actual s2n-quic crate, at least not at first. It could live in a specific integration crate that applications opt into by adding it to their dependencies. T

My sense is that for async-std it would make sense to live alongside here, as in my experience it helps having two similar but slightly different executors as test cases for any abstraction API. For less used runtimes, and especially for experiments, having an example around how to add your own runtime outside would be great.

[camshaft]

The more general question for me comes from wanting to make sure there is a path for potential other runtimes later down the line.

Makes sense. The library is built in a way to try and make this as easy as possible. Like I said, even if it isn't "officially" supported, you should be able to write a provider for any runtime that provides functionality to send/receive datagrams and arm timers.

My sense is that for async-std it would make sense to live alongside here, as in my experience it helps having two similar but slightly different executors as test cases for any abstraction API.

I'm fine with it living in this repository but I think initially, before committing to it in the s2n-quic crate, we should have a s2n-quic-async-std crate that does the integration. Applications wanting to use async-std can depend on that directly and pass an instance to the .with_io() method. If the usage of async-std becomes widely adopted for this crate we can consider making it an official feature flag of the s2n-quic crate. Does that make sense?

Would you be able to work on the integration crate and submit a PR? I'm not sure how soon we'd be able to implement it, otherwise.

[dignifiedquire]

I made a first version here: https://github.com/dignifiedquire/s2n-quic-async-std, based on the tokio implementation. Currently Select is not exported, would that be possible, or should I copy this into the new crate?

[camshaft]

Very nice! Thanks for getting it started :smiley:. It looks like the implementation shares a lot of the tokio code, which is good. I would actually be fine to put it in s2n-quic-platform to make it easy and then the s2n-quic-async-std crate would just enable that with the async-std feature, export the impl and implement io::Provider for it.

[zicklag]

You'd be open to a PR that gives a way to disable the tokio dependency, then, right?

I'm looking around at different QUIC implementations to use in the Bevy game engine, and it uses smol for it's executor, so I'd like to use that instead of adding another executor.

[camshaft]

Yep, it makes sense to have a way of disabling the default.

[ghost]

I would love to contribute to this, but there is no documentation for io::Provider.