Am I misusing tokio's max_blocking_threads and spawn_blocking?

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.

Yes, you are misusing max_blocking_threads. Use a Semaphore to limit the number of files being processed instead.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.