net: warn on creating a tokio socket from a blocking one #7166

Noah-Kennedy · 2025-02-20T03:52:57Z

This adds a warning when constructing a tokio socket object from an underlying std socket that is not set to nonblocking mode.

This warning is likely to incrementally turn into a hard error in the future.

See #5595. This adds a warning when constructing a tokio socket object from an underlying std socket that is not set to nonblocking mode. This warning is likely to incrementally turn into a hard error in the future.

Noah-Kennedy · 2025-02-20T04:51:50Z

Windows does not support this, so it only works on unix for now.

jeff-hiner · 2025-02-20T15:57:46Z

tokio/src/util/blocking_check.rs

+        let sock = socket2::SockRef::from(s);
+
+        if !sock.nonblocking()? {
+            eprintln!("Warning: registering a blocking socket, this may be a bug!");


Is it possible/likely that users are already using stderr for other things? Emitting stderr from within a library feels kinda gross; it might be easier to spot if we just panic here.

I actually feel similarly, the request to do it this way specifically came from @carllerche.

I'll leave it up to him to voice why he wants this approach.

I spent some more time thinking about this question. I think that I am OK starting with a debug_assert. I would like there to be a way to disable the assertion (in case a user has a legitimate case) , and the panic message links to an issue for the user to find out how to disable the panic and report their legitimate use case.

To disable the panic, we can use a tokio_allow_from_blocking_fd cfg flag or something similar. The linked issue can include steps for setting it.

cc/ @Darksonn wdyt?

Using a debug assertion with a --cfg to disable it seems preferable to the eprintln!.

Ten0

Thanks for getting this to move forward!

Is from_std_set_nonblocking/from_std_assume_nonblocking still the long term plan?

Or will it instead be something where tokio sets it to nonblocking, like axum_server currently does?
Or will the panic be considered to be enough?

Noah-Kennedy · 2025-02-20T21:50:24Z

Thanks for getting this to move forward!

Is from_std_set_nonblocking/from_std_assume_nonblocking still the long term plan? Or will it instead be something where tokio sets it to nonblocking, like axum_server currently does? Or will the panic be considered to be enough?

I think there's a bit that needs figured out still about what we do going forward. The trouble with the prior suggestion is that we actually still have the issue of TryFrom to figure out - we can't exactly deprecate that, and we need to figure out whether what it's behavior will be.

I think our two long-term options here are going to be to either panic, or set the socket option silently, and there's good arguments to be made for both. There should also be something along the lines of from_std_unchecked or from_std_assume_nonblocking, of course.

Given that we either need to leave the footgun in TryFrom or make a behavioral change anyways, I don't think leaving from_std as is makes much sense.

Darksonn

This also needs review from Carl before it can be merged.

Darksonn · 2025-02-21T10:11:18Z

tokio/src/util/mod.rs

+#[cfg(feature = "net")]
+pub(crate) mod blocking_check;


Consider re-exporting check_socket_for_blocking here to make the imports more nice.

Darksonn · 2025-02-21T10:12:12Z

tokio/src/util/blocking_check.rs

+        let sock = socket2::SockRef::from(s);
+
+        if !sock.nonblocking()? {
+            eprintln!("Warning: registering a blocking socket, this may be a bug!");


The warning should say that it comes from Tokio. Perhaps include Location::caller via #[track_caller] to print the caller location.

Darksonn · 2025-02-21T10:15:52Z

tokio/src/net/tcp/listener.rs

@@ -209,6 +210,8 @@ impl TcpListener {
    /// will block the thread, which will cause unexpected behavior.
    /// Non-blocking mode can be set using [`set_nonblocking`].
    ///
+    /// Tokio's handling of blocking sockets may change in the future.


Can we improve this wording? I don't think it very clearly explains the situation. You could say something along the lines of "Passing a listener in blocking mode is always errornous, and the behavior in that case may change in the future. For example, it could panic."

carllerche · 2025-02-24T19:12:03Z

tokio/src/util/blocking_check.rs

+
+#[cfg(unix)]
+#[allow(unused_variables)]
+pub(crate) fn check_socket_for_blocking<S: AsFd>(s: &S) -> crate::io::Result<()> {


Why does this return io::Result? It doesn't seem like the fn needs a return argument.

carllerche · 2025-02-24T19:12:43Z

tokio/src/net/tcp/listener.rs

@@ -5,6 +5,7 @@ cfg_not_wasi! {
    use crate::net::{to_socket_addrs, ToSocketAddrs};
 }

+use crate::util::blocking_check::check_socket_for_blocking;


Very minor and not a needed change to merge, but IMO this check makes more sense in the net module.

carllerche · 2025-02-24T19:17:02Z

tokio/src/util/blocking_check.rs

+        let sock = socket2::SockRef::from(s);
+
+        if !sock.nonblocking()? {
+            eprintln!("Warning: registering a blocking socket, this may be a bug!");


I spent some more time thinking about this question. I think that I am OK starting with a debug_assert. I would like there to be a way to disable the assertion (in case a user has a legitimate case) , and the panic message links to an issue for the user to find out how to disable the panic and report their legitimate use case.

To disable the panic, we can use a tokio_allow_from_blocking_fd cfg flag or something similar. The linked issue can include steps for setting it.

cc/ @Darksonn wdyt?

Noah-Kennedy and others added 6 commits February 19, 2025 21:52

net: warn on creating a tokio socket from a nonblocking one.

c7893f6

See #5595. This adds a warning when constructing a tokio socket object from an underlying std socket that is not set to nonblocking mode. This warning is likely to incrementally turn into a hard error in the future.

fmt

179a409

that operating system is a decades-old mistake

430d100

docs.rs doesnt have windows so im guessing

4e5fea5

wat

def2dd8

Merge branch 'master' into noah/warnings

935b4ce

Noah-Kennedy added 2 commits February 19, 2025 22:54

sadness

1c6da67

lol what was i doing

ee89f64

Noah-Kennedy changed the title ~~net: warn on creating a tokio socket from a nonblocking one.~~ net: warn on creating a tokio socket from a nonblocking one Feb 20, 2025

Darksonn requested a review from carllerche February 20, 2025 08:00

Darksonn added A-tokio Area: The main tokio crate M-net Module: tokio/net labels Feb 20, 2025

rupert648 approved these changes Feb 20, 2025

View reviewed changes

Noah-Kennedy changed the title ~~net: warn on creating a tokio socket from a nonblocking one~~ net: warn on creating a tokio socket from a blocking one Feb 20, 2025

Noah-Kennedy requested a review from Darksonn February 20, 2025 15:22

jeff-hiner reviewed Feb 20, 2025

View reviewed changes

Ten0 approved these changes Feb 20, 2025

View reviewed changes

Noah-Kennedy enabled auto-merge (squash) February 20, 2025 21:51

Darksonn reviewed Feb 21, 2025

View reviewed changes

carllerche requested changes Feb 24, 2025

View reviewed changes

Darksonn mentioned this pull request Feb 25, 2025

net: Consider having from_std panic on blocking sockets #7172

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

net: warn on creating a tokio socket from a blocking one #7166

net: warn on creating a tokio socket from a blocking one #7166

Noah-Kennedy commented Feb 20, 2025 •

edited by Darksonn

Loading

Noah-Kennedy commented Feb 20, 2025

jeff-hiner Feb 20, 2025

Noah-Kennedy Feb 20, 2025

carllerche Feb 24, 2025

Darksonn Feb 24, 2025

Ten0 left a comment •

edited

Loading

Noah-Kennedy commented Feb 20, 2025

Darksonn left a comment

Darksonn Feb 21, 2025

Darksonn Feb 21, 2025

Darksonn Feb 21, 2025

carllerche Feb 24, 2025

carllerche Feb 24, 2025

carllerche Feb 24, 2025

net: warn on creating a tokio socket from a blocking one #7166

Are you sure you want to change the base?

net: warn on creating a tokio socket from a blocking one #7166

Conversation

Noah-Kennedy commented Feb 20, 2025 • edited by Darksonn Loading

Noah-Kennedy commented Feb 20, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ten0 left a comment • edited Loading

Choose a reason for hiding this comment

Noah-Kennedy commented Feb 20, 2025

Darksonn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Noah-Kennedy commented Feb 20, 2025 •

edited by Darksonn

Loading

Ten0 left a comment •

edited

Loading