tokio-uring
tokio-uring copied to clipboard
Provide example showing a file descriptor leak
Provide an example where a single binary both calls TCP listen accept and connect, and that tracks the file descriptor values, to show that the tokio_uring accept operation can leak file descriptors if it is canceled at an inopportune time: when the uring accept operation is being run by the kernel, a client makes the connection, but the server side has canceled the future.
It's a small time window where this can happen, but it shows potentially a larger problem when uring operations in flight and having to deal with cleanup when the future is cancelled.
Run with
cargo run --release --example investigate_accept_socket_leak
It will list the open file descriptors to stdout for a few rounds and will finish with an error if file descriptor leaks were evident.
Wanted to get the reproducer committed to GitHub, one way or the other, so I didn't have to keep track of it locally. Will update the open Issue with this PR. Even if this PR doesn't get merged, it is useful to see how the file descriptor leak can be reproduced by a single binary.