Sqlx: Usage with tokio

[PvdBerg1998]

First off, the project looks awesome! I'm currently using mysql_async with tokio and not completely satisfied. I'd love to give this crate a try, but I saw you're using async_std. My question is: how much do you rely on it?

I would like to keep everything running on a single threadpool which I can control. I'm using other libraries bound to tokio, so I can't switch over. Would it be possible to decouple from async_std or perhaps provide some feature flags to support tokio aswell? Again, it depends on what functionality you're using it for.

[abonander]

We went with async-std because we wanted to use this lib in web apps built with Tide, which is now also on async-std.

It would probably be a pretty major refactor to support Tokio. We use async_std quite heavily. If they were Cargo features we would have to treat them as mutually exclusive which is an antipattern, and it would require spewing #[cfg(all(feature = "async-std", not(feature = "tokio")))] and vice versa all throughout the code, which is not an exciting prospect.

Tokio also doesn't have an MPMC + FIFO channel which Pool uses in its RAII implementation for connections (to release them back to the pool), but we could probably find a replacement for that.

We also want to use async_native_tls for supporting secured connections, the API of which is based on the I/O traits from futures, which async-std uses but Tokio doesn't.

[PvdBerg1998]

I agree that it's not desirable to have a large amount of feature gated code. Perhaps we can list the specific features you require from async_std and see when any runtime independent alternatives become available. The split between tokio and async_std is unfortunate, I hope there will be some abstraction over runtimes soon.

[mehcode]

Specifically we require the MPMC channels for our Pool implementation. See https://github.com/launchbadge/sqlx/blob/master/sqlx-core/src/pool/inner.rs#L26

---

Note that I believe we're okay with accepting a PR here but at the same time I know that I'm not going to spend any time on this due to a massive list of other things I'd like to see SQLx have that I find more interesting to work on.

For anyone interested though, I would expect two cargo feature flags, runtime-async-std and runtime-tokio with the former on-by-default ( for ease-of-use ). I would additionally expect an explicit compile error raised from the crate root if both features are on-by-default.

---

@abonander Not sure the right way to word a label for this issue. I added [wontfix] and [help wanted] for now.

[jjpe]

@mehcode the mpmc issue is easily fixed by using crossbeam, it has mpmc channels that are stdlib API-compatible and have better performance than std::mpsc to boot.

[abonander]

We want specifically async MPMC channels; the one in Crossbeam is a blocking channel.

[jjpe]

Ah. I'm not aware of any channels (MPSC or otherwise) that are built on top of async infrastructure.

[mehcode]

This will be in 0.2.0

[PvdBerg1998]

Oh wow, cool! I'll check it out asap!

[kevlarr]

Well that was pretty crazy turnaround, nice work!

[mehcode]

tldr., after some internal refactoring (that was not done for this) it ended up being a simple change at the end so I just went and did it.