Prefer tokio runtime everywhere

[thomaseizinger]

Description

Historically, examples and tests in rust-libp2p have used a mix of the async-std and tokio runtime. These days, both runtimes are equally well supported by the library but the examples and tests are still mixed. For now, we want to keep supporting async-std but all examples and tests should use the tokio runtime.

Motivation

The tokio runtime is much more well established and better maintained. Users should be able to use other runtimes or bring their own.

Current Implementation

Both runtimes are being mixed.

[P1R]

I want to work on this issue since it will help me to understand more the project, and test my nodes environment. So far I identified the missing files and examples to be able to solve this issue.

Refactor Examples

• [ ] relay-server
• [x] distributed-key-value-store
• [x] identify
• [x] rendezvous

Tests

test are located in the tests directory of each item

• [ ] transports/quic(smoke.rs and stream_compliance.rs)
• [ ] protocols/dcutr(lib.rs)
• [x] protocols/ping(ping.rs)
• [ ] protocols/gossipsub(smoke.rs)
• [ ] protocols/autonat(test_client.rs, test_server.rs)
• [ ] protocols/mdns(use-async-std.rs)
• [ ] protocols/identify(smoke.rs)
• [ ] protocols/relay(lib.rs)
• [ ] protocols/kad(client_mode.rs)
• [ ] protocols/request-response(peer_address.rs, ping.rs, error_reporting.rs)
• [ ] swarm(connection_close.rs, listen.rs)
• [ ] core(transport_upgrade.rs)
• [ ] muxers/yamux(compliance.rs)
• [ ] muxers/mplex(compliance.rs)

Tutorials New Issue

Update issue #5559 examples/ping already has the tokio implementation, but the Tutorial has the async-std so I am not sure if this can be added or as a separate issue?

• [x] src/tutorials/ping.rs)

[jxs]

thanks @P1R!

[jxs]

with https://github.com/rust-netlink/netlink-sys/pull/24#issuecomment-2483767352 breaking our CI I'd say we should accelerate and make deprecation of async-std official, wdyt @guillaumemichel @dariusc93 @elenaf9 @drHuangMHT

[jxs]

@hanabi1224 submitted https://github.com/rust-netlink/netlink-sys/pull/25, let's wait for its development and see. @lyzkov you reacted with a thumbs down on my comment above, are you an async-std user? If so can you elaborate on why you use it instead of tokio, if not can you elaborate on if and why you oppose the decision to deprecate it? Thanks!

[lyzkov]

@jxs async-std is currently supported by uniffi bindings in UDL language mode (which crosscompiles much faster than annotations mode that support both tokio and async-std). If uniffi would add support for tokio in UDL then everything would be all right.

Nonetheless, this is not such a big deal for me. The cost is compiler time which is much less than time spent on discovering Rust. If there are serious issues with async-std comparing to tokio then I would go for what's better for libp2p.

[elenaf9]

I went through the repo. Still missing right now are the tests in:

• [ ] multistream-select
• [x] rw-stream-sink (open PR: #6023)
• [x] mplex
• [x] request-response (open PR: #5857)
• [x] swarm
• [x] uds
• [x] websockets

They still use async_std as executor in their tests and need to be changed to use tokio instead.

[PoulavBhowmick03]

Hey @elenaf9 , may I open a PR addressing the tests in multistream-select to use tokio ?

[elenaf9]

Hey @elenaf9 , may I open a PR addressing the tests in multistream-select to use tokio ?

@kamuik16 are you currently working on that? If not, sure @PoulavBhowmick03! Thanks.

[kamuik16]

Hey @elenaf9 , may I open a PR addressing the tests in multistream-select to use tokio ?

@kamuik16 are you currently working on that? If not, sure @PoulavBhowmick03! Thanks.

Go ahead @PoulavBhowmick03.

[PoulavBhowmick03]

Hey @elenaf9 , may I open a PR addressing the tests in multistream-select to use tokio ?

@kamuik16 are you currently working on that? If not, sure @PoulavBhowmick03! Thanks.

Go ahead @PoulavBhowmick03.

Thanks!