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

Dependence on tokio runtime #72

Open
PvdBerg1998 opened this issue Sep 19, 2019 · 3 comments
Open

Dependence on tokio runtime #72

PvdBerg1998 opened this issue Sep 19, 2019 · 3 comments

Comments

@PvdBerg1998
Copy link

Disclaimer: This issue is supposed to be a discussion.

I think, with the upcoming async/await, other runtimes will appear. There are already 3 "large" ones: tokio, futures and async-std. Therefore in my opinion it's a bad thing to have a hard dependency on tokio for task spawning. I believe it's runtime is used for some background cleanup.

What do you think about this?

@PvdBerg1998
Copy link
Author

Cc @jonhoo because you're working on the fut 0.3 port

@jonhoo
Copy link
Contributor

jonhoo commented Sep 19, 2019

So, I think the biggest challenge here is the lack of a common trait for AsyncRead and AsyncWrite. Beyond that, I don't think the 0.3 port really depends on tokio in any particularly substantial way. The issues to track here are probably:

rust-lang/futures-rs#1818
async-rs/async-std#54
tokio-rs/tokio#1297
tokio-rs/tokio#1551

Until there's some kind of resolution to these, are isn't really a way to be generic over the runtime (sadly). Once there is, it should be fairly straightforward to make mysql_async applicable to any runtime.

@udoprog
Copy link
Contributor

udoprog commented Sep 30, 2019

Note I believe OP is referencing the use of spawn and timer, which currently are hard dependencies on a tokio runtime.

Use of tokio::spawn:
https://github.com/blackbeam/mysql_async/blob/master/src/conn/pool/mod.rs#L203

Use of tokio::timer:
https://github.com/blackbeam/mysql_async/blob/master/src/conn/pool/mod.rs#L641

Unfortunately none of the ecosystem is currently moving in a direction that would allow a library to decouple such features. That would either require building APIs that can interact generically with the underlying runtime over task-local storage, or use a wrapper (with the associated runtime and complexity cost) like runtime.

I'm not sold on the latter approach for libraries so far, and task-local storage is not available in std::future.

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

3 participants