about block_in_place()

[JesseAtSZ]

It is mentioned on the api docs that block_in_place() turns a core thread into a blocking thread. I have a question about this: the default number of core threads is the number of CPU cores. If I use block_in_place(), will it reduce the number of core threads? Will call block_in_place() frequently cause core threads unavailable? Or maybe that every time a core thread becomes a blocking thread, a new core thread will be added to keep the number of core threads consistent with the number of CPU cores?

[Darksonn]

Whenever you use block_in_place, the runtime will start a new worker thread using spawn_blocking so the number of worker threads remains constant unless the spawn_blocking queue is full, preventing the new worker thread from starting.

[BCathcart]

What is the behaviour when when using block_in_place while the spawn_blocking queue is full? In the spawn_blocking rust docs it mentions

Tokio will spawn more blocking threads when they are requested through this function until the upper limit configured on the Builder is reached. After reaching the upper limit, the tasks are put in a queue.

What I seem to see in practice is that the blocking operation executes on the regular worker thread calling block_in_place when we've reached the max number of blocking threads, rather than be queued waiting for a blocking thread to be free.

[Darksonn]

If the spawn_blocking pool is full, then the new worker thread will not be spawned until existing tasks exit. So in that case, you "lose" a worker thread from your runtime until either block_in_place returns or space frees up on the spawn_blocking threadpool.

If block_in_place is used heavily, then in the worst case, you may end up without any worker threads at all.