Tokio 0.1.3 satisfying a futures::future::Executor

help
1

Hi! So I'm trying to get the default runtime in tokio working with redis-async-rs (redis-async crate). This is the function I'm trying to call (from that project)

pub fn paired_connect<E>(addr: &SocketAddr, executor: E) -> PairedConnectionBox
where
    E: Executor<Box<Future<Item = (), Error = ()> + Send>> + 'static,
{

I'm attempting to pass it the default executor:

use redis_async::client;
use tokio::executor::DefaultExecutor;

client::paired_connect(&addr, DefaultExecutor::current())

And it gives me this:

the trait `futures::future::Executor<std::boxed::Box<
  futures::Future<Error=(), Item=()> + std::marker::Send + 'static>
>` is not implemented for `tokio::executor::DefaultExecutor`

I'm not really sure where to go from here. Any help would be much appreciated.

github/redis-async-rs

2

So... I made a terrible change to the crate to get it to compile. Very open to better ideas (not sure if it panics yet).

https://gist.github.com/brigand/efd5328db5a4209e5212cd76b12693cc

3

It looks like the redis crate hasn’t been updated to support the new (“reformed”) tokio. The Executor it wants is the “old” Executor trait, not the new one.

Did you specifically want to use the latest tokio with this crate?

4

The latest version of redis-async was published before the recent changes to Tokio that included the new Tokio Runtime, as such it uses the Executor trait from futures-rs instead. The Tokio DefaultExecutor doesn't implement the Executor trait from futures so we get the compilation error. (Using the new Tokio thread-pool does work, because that does implement Executor from Futures, as well as the Tokio Executor)

I think the reason why DefaultExecutor is implemented this way is in anticipation of Futures 0.2 which is expected to change these traits.

As such I'm considering waiting for Futures 0.2 before updating redis-async, to allow these areas to settle down. Although, now that I think of it, given that DefaultExecutor exists, and is intended to be a permanent fixture I believe, I'm thinking the next change might be to use that internally within redis-async and not to require any executors to be provided. This should mean any future changes are internal and won't change the external API again.