search

tokio-rs / tokio

A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...
https://tokio.rs
MIT License
25.44k stars 2.3k forks source link

Unstable ErrorKind in Stable branch #6650

Closed dr-kernel closed 2 weeks ago

dr-kernel commented 2 weeks ago

Version 1.38

Platform Linux 5.15.0-107-generic #117-Ubuntu SMP Fri Apr 26 12:26:49 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Description Using a crate tokio-modbus which uses TcpStream to connect to a client. If this client isn't available (like the device is offline) I get the error: Os { code: 113, kind: HostUnreachable, message: "No route to host" } Looking up this "kind" is points me to https://github.com/rust-lang/rust/issues/86442 https://github.com/rust-lang/rust/blob/a9c8887c7d548abc6c3e87f7d6fa02a0e95880bd/library/std/src/io/error.rs#L229-L230 This error is in the unstable branch. Why does TcpStream::connect() use this when I don't use the nightly? tokio = { version = "1", features = ["full"] } I couldn't actually find where this ErrorKind variant is throw aside from https://github.com/tokio-rs/tokio/blob/9a75d6f7f70fd81f589a8209c548944bc3d05f84/tokio/src/net/tcp/socket.rs#L638-L641 which is likely an OS error?

I expected to see this happen: See one of the stable io::Error::ErrorKinds: 

 | ErrorKind::ConnectionRefused
 | ErrorKind::ConnectionReset
 | ErrorKind::ConnectionAborted

or the like The one that's being returned is appropriate but I cannot use it if i want to continue to use stable.

Instead, this happened: Os { code: 113, kind: HostUnreachable, message: "No route to host" }

dr-kernel commented 2 weeks ago

Seems that this is a sync problem between stable and nightly use of ErrorKind. https://doc.rust-lang.org/stable/src/std/sys/pal/unix/mod.rs.html#261 I'll leave this open for now, but doesn't seem to be a tokio-rs problem but a rust std problem.

Darksonn commented 2 weeks ago

Tokio will often rely on the standard library for various kinds of logic, and when we do so, we are subject to the choices that the standard library makes. There isn't anything we can do about it.

Closing as wont-fix.