net: debug_assert on creating a tokio socket from a blocking one#7166
Conversation
|
Windows does not support this, so it only works on unix for now. |
There was a problem hiding this comment.
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 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 Given that we either need to leave the footgun in |
Darksonn
left a comment
There was a problem hiding this comment.
This also needs review from Carl before it can be merged.
| use crate::net::{to_socket_addrs, ToSocketAddrs}; | ||
| } | ||
|
|
||
| use crate::util::blocking_check::check_socket_for_blocking; |
There was a problem hiding this comment.
Very minor and not a needed change to merge, but IMO this check makes more sense in the net module.
07f2dd9 to
31f24d8
Compare
|
@carllerche @Darksonn I have updated the PR and addressed the feedback. This is ready for re-review. |
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.
|
from offline discussion with @Darksonn: need to wrap the lines on the docs to not be super long this is good to merge after that is done |
carllerche
left a comment
There was a problem hiding this comment.
Small proposal for the panic message.
Co-authored-by: Carl Lerche <me@carllerche.com>
required due to latest version of tokio panicking if not set. tokio-rs/tokio#7166
required due to latest version of tokio panicking if not set. tokio-rs/tokio#7166
… axum-server 8cdb2d9 fix: set TcpListener to non-blocking mode before passing to axum-server (Jose Celano) Pull request description: ## Description This PR fixes the Tokio runtime panic that occurs when running the application with `cargo run`. ## Problem The application was panicking with: ``` Registering a blocking socket with the tokio runtime is unsupported. If you wish to do anyways, please add `--cfg tokio_allow_from_blocking_fd` to your RUSTFLAGS. ``` ## Root Cause - Tokio 1.44.0 introduced stricter validation to prevent blocking file descriptors from being registered with the async runtime - `std::net::TcpListener::bind()` creates blocking sockets by default - axum-server 0.8.0 internally uses `tokio::net::TcpListener::from_std()` which panics when it detects a blocking socket ## Solution Set the `TcpListener` to non-blocking mode **before** passing it to axum-server by calling `socket.set_nonblocking(true)` immediately after binding. ## Changes - ✅ Added `socket.set_nonblocking(true)` in `src/api/mod.rs` after binding the TcpListener - ✅ Removed the incorrect RUSTFLAGS workaround from README.md troubleshooting section - ✅ Deleted temporary TOKIO_BLOCKING_SOCKET_FIX.md file ## Benefits - Proper fix instead of masking the symptom with RUSTFLAGS - Prevents potential performance issues under load - Application now runs correctly with just `cargo run` ## Testing Verified that the application starts successfully without any panic: ```bash cargo run ``` Fixes #8 ## References - [Tokio Issue #7172](tokio-rs/tokio#7172) - [Tokio PR #7166](tokio-rs/tokio#7166) ACKs for top commit: josecelano: ACK 8cdb2d9 Tree-SHA512: 12653e0a924f03fb6e43d9eb381aec6e593227f2a095ba681b952c3851ed09575a2a5cbca2b0fd6d0647d9c777d4a28418bc51e768568f618457614c34b02b15

See #5595 and #7172.
This adds a debug assertion that checks that a supplied underlying std socket is set to nonblocking mode when constructing a tokio socket object from such an object.
This only works on unix.