Dependence on tokio runtime

[PvdBerg1998]

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]

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

[jonhoo]

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:

https://github.com/rust-lang-nursery/futures-rs/issues/1818 https://github.com/async-rs/async-std/issues/54 https://github.com/tokio-rs/tokio/issues/1297 https://github.com/tokio-rs/tokio/issues/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]

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.