Hi all,
I spent the morning trying to debug an issue with my code where connecting to a udp socket seemed to be blocking (or awaiting) until all my own spawn_blocking calls had completed.
I had used max_blocking_threads to limit the number of parallel spawn_blocking executions as my code was doing some hashing of files on a slow media source and I wanted to limit how many files I was trying to read at any one time.
I eventually tracked it down to the fact I was using a dns name in the UdpSocket::connect call, which had to be resolved, and uses a spawn_blocking call to do so (relevant code)
Now that I know what's happening, I can fix it by doing the connect before my own spawn_blocking calls. Previously, I was (pointlessly) trying to avoid creating the socket if it wasn't needed as there is a lot of caching of the server responses and I often don't need the socket at all.
But the fact that I hit this at all makes me feel like i'm doing something wrong with my usage of max_blocking_threads and spawn_blocking.
Here's a (kinda) minimal version of my real world use case without any of the caching: Code shared from the Rust Playground · GitHub (Cargo.toml and server to connect to in the comments).
Am I perhaps abusing the max_blocking_threads configuration for something that I should be using a different mechanism to handle limiting the number of hashing threads I have? I originally thought I'd need to fire up some threads and use channels to send hashing requests/responses, and was happy to find tokio had a threadpool i could use out of the box.