Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove tokio I/O traits from dependencies #720

Open
notgull opened this issue Oct 28, 2023 · 5 comments
Open

Remove tokio I/O traits from dependencies #720

notgull opened this issue Oct 28, 2023 · 5 comments

Comments

@notgull
Copy link
Contributor

notgull commented Oct 28, 2023

Would it be accepted to replace the tokio I/O traits with more general I/O traits, like what happened in hyper? If so, I can implement this.

@seanmonstar
Copy link
Member

I think this is something we could do, though it would be a breaking change and highlighting why it's worth it, and also how we would track the differences with hyper, would be good to do.

@notgull
Copy link
Contributor Author

notgull commented Nov 1, 2023

, though it would be a breaking change and highlighting why it's worth it

It would enable usage of hyper and h2 in runtimes that aren't tokio.

also how we would track the differences with hyper,

Maybe we can extract the hyper traits into a separate crate?

@seanmonstar
Copy link
Member

Hm. It's already been possible to use hyper and h2 with different runtimes. I've seen hyper 0.14 work with curl, async-std, and Fuchsia. Using just the traits from Tokio doesn't make it use the runtime, or even enable all the runtime code. The reason why hyper made its own traits was to be able to update them independently for eventual io-uring upgrades. I don't really want to extract those traits to a separate crate, I don't mean for them to be used throughout the ecosystem. They're just how to hook into hyper.

That said, I do still think this is something that could be done for h2, with other motivations brought up.

@daxpedda
Copy link

I think the idea is to not bring in Tokio as a dependency at all while still being able to use h2.

@nanoqsh
Copy link

nanoqsh commented Sep 19, 2024

That said, I do still think this is something that could be done for h2, with other motivations brought up.

Tokio is a great runtime and is a good default choice. However, for such a fundamental library as h2 forcing runtime is too intrusive. It would be great to get rid of tokio as a dependency completely, even though you can use any runtime on top of it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants