RFC: Line event stream support for Tokio

[mgottschlag]

The second commit (on top of #34 for my convenience, but completely independent) adds support for asynchronous handling of line events/interrupts based on Tokio. This patch probably fixes #18 .

This probably needs some further discussion:

• I set the Rust edition to 2018 to be able to use async/await in the example.
• The API is just a light wrapper around LineEventHandle. I implemented AsRef<LineEventHandle> instead of adding a separate get_value() function. Do we want a function to destroy an AsyncLineEventHandle and get the original LineEventHandle back?
• I placed the type in an async_tokio module and behind an async_tokio feature flag, under the expectation that one day there might be wrapper types for other async I/O frameworks (async_std?) as well.

[mgottschlag]

This is horribly wrong - I'll update the PR once it's fixed.

[mgottschlag]

Now it should be in a state where feedback would be appropriate. I can rebase it on master if you do not want to merge #34 (right now, this is the version I use for development).

I tested both the async_tokio and the gpioevents example, and they seem to work.

[fpagliughi]

Apologies, I've been slammed at work this week, but want to give this a proper look soon, because it really would be a cool feature to add. (Not that I have write access here, but still a vested interest).

My opinion on libraries at this level has now become that we should try to resist selecting one runtime over another. I might use this lib with any runtime, and even if the runtime is not exposed in the API, having to compile both tokio and another runtime adds a bit of code to the build.

There isn't much tokio here. Couldn't we just up the MSRV to 1.39 and use standard futures and streams?

[mgottschlag]

While it might be possible to build directly upon mio instead of using Tokio, I don't think that would be of much use.

When I looked at async-std for a similar problem, I found that they don't have proper support for custom Evented event sources: async-rs/async-std#293 and async-rs/async-std#626

[tchamelot]

I looked at this PR and I have done something similar lately.

I feel that the mio abstraction should be available as is and not only through an async function relying on tokio. To do that you could remove the PollWrapper which seems useless to me and directly implement Evented for LineEventHandle.

Like in rust-embedded/rust-sysfs-gpio , it would be nice to hide mio behind a feature and tokio behind another one which relies on mio.

[posborne]

@mgottschlag @tchamelot Sorry for missing this when it first came in. It's been an interesting past few months!

[posborne]

I believe it's slightly more idiomatic to write this as:

while let Some(event_result) = events.next().await {
    let event = event_result?;
    println!("{:?}", event);
}

[posborne]

CI is failing due to a requirement in 1.38 it looks like. @mgottschlag could you bump the msrv to 1.38.0?

[posborne]

bors r+

[bors]

Build succeeded:

• continuous-integration/travis-ci/push