socket leak? #1
Description
While I know this crate is experimental and in active development, I'm attempting to use it for an esp32s3 project since using async-io results in stack overflows I'm not able to avoid.
async-io-mini works great for the first 9 (CONFIG_LWIP_MAX_SOCKETS-1) calls to Async::<TcpStream>::connect, and then panics on the 10th:
thread '<unnamed>' panicked at /Users/jesse/.rustup/toolchains/esp/lib/rustlib/src/rust/library/std/src/os/fd/owned.rs:165:9:
assertion `left != right` failed
left: -1
right: -1
(If I increase CONFIG_LWIP_MAX_SOCKETS to the maximum of 16, then it will fail on the 15th iteration. I'm assuming the other socket is being used for wifi.)
I've confirmed this only occurs when using this crate with a modified version of the esp-idf-svc tls_async example: https://gist.github.com/jvatic/2ad238eb05dbe60919f7cfa338085c15. Using async-io it will either stack overflow or run 10 successful iterations, and using async-io-mini it will run 9 successful iterations before exiting with the above panic on the 10th.
Is this an issue you're aware of? I've poked around to try and see why the sockets aren't being released without much luck so far, so thought I'd ask. (And I'm happy to contribute if you can point me in the right direction!)
I've tried calling libc::shutdown and libc::close directly with the fd (from Async::<TcpStream>::into_inner().unwrap().into_raw_fd()) at the end of the loop in an attempt to mimic this c example, but that doesn't resolve the apparent socket leak.