async_std support?

[manuels]

This is a well crafted crate. Thanks for implementing it!
Is there a plan to make it work with async_std instead of tokio?

[little-dude]

Hello,

That's something I'd love to have, but I have little time these days, so I'm not working on new features. However I'd gladly accept a PR for this.

Perhaps we should discuss first how to do this though. Currently, there are two places where we have tokio specific code:

• tokio.rs in netlink-sys: https://github.com/little-dude/netlink/blob/master/netlink-sys/src/tokio.rs. Here we just implement PollEvented for the netlink socket so that we can use it with the tokio runtime. I was initially waiting for Expose net::driver::Watcher mechanism async-rs/async-std#293 to be solved, because as far as I understand, this would automatically make the socket compatible with async-std. There may be a better solution for this, but I haven't used async-std myself, so I'm not sure.
• then there's the netlink-proto where we use tokio_util::codec in the transport layer. I think this could probably be refactored without too much effort to be framework agnostic, so it's less of a problem

[joshtriplett]

As noted in in the link to smol, the first item isn't needed at all; because you implement AsRawFd, polling just works. So you'd just need a feature flag to enable tokio support to avoid the dependency.

The second item would require some modification to use smol functions rather than tokio, so that would have to be conditional.

[gabrik]

I really need this support, I can take care of the implementation.
Where I should add this code? Inside the netlink-sys crate?

[little-dude]

netlink-sys already supports smol since #104.

The biggest piece is actually netlink-proto, which uses tokio in some places. Ideally I'd like to re-write these portions with non tokio specific bits, but it's not so trivial and I've been postponing this refactoring for a long time. I'd love some help with this and will take time to review any PR. Before starting it would be nice to discuss a plan though.

[gabrik]

Sure, I'll take a look at the code to understand what the code does and I'll come back with more thoughts on this.

[little-dude]

It's not too bad actually. I think we only use use tokio_util::codec::{Decoder, Encoder}; so we could just depend on tokio_util with the codec feature. Beyond this, we also need to change this in lib.rs:

pub mod sys {
    pub use netlink_sys::{protocols, SocketAddr, TokioSocket as Socket};
}

Maybe we can add a smol or async_std feature flag and choose another socket if compiling with that flag. By default we'd still compile with tokio support. Would that be fine? I wonder how other crates support multiple async frameworks these days.

[gabrik]

That is correct, other crates usually use features to select the async framework.
I guess that just depend on tokio_util and then depending on the feature we use tokio or async_std, with tokio as the default feature it is more than fine.

I also think that this feature should be re-exposed also by the creates that depend on netlink-proto in order to allow the user to select the needed one.

[JohnTitor]

Implemented by #144.