You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
(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.)
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.
The text was updated successfully, but these errors were encountered:
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 toAsync::<TcpStream>::connect
, and then panics on the 10th:(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 usingasync-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
andlibc::close
directly with the fd (fromAsync::<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.The text was updated successfully, but these errors were encountered: