Why doesn’t block_in_place switch the thread pool of the Future, but instead switches the thread’s pool?

[Jason5Lee]

I thought of this issue while deciding whether to use spawn_blocking (which requires some extra cloning to handle lifetimes) or block_in_place. If I understand correctly, the principle behind block_in_place is to switch the current thread to the IO thread pool. However, my idea was to switch the Future instead. Conceptually, block_in_place could become an async function that yields at the start and end. After the initial yield, the Future would be sent to the IO thread pool, polled once to execute the code block until the next yield, and then return to the original thread pool. This approach could combine the benefits of both block_in_place and spawn_blocking. Are there any potential issues with this that I might have overlooked?

[ADD-SP]

If I understand correctly, the principle behind block_in_place is to switch the current thread to the IO thread pool. However, my idea was to switch the Future instead.

The block_in_place does the following steps.

1. Sending the local Futures to a freshly spawned worker thread if the current thread is a worker thread.
2. Invoking the input blocking closure.
3. Terminate the current thread.

It never convert the current thread to a worker thread, it just spawns a new worker thread an send the local Futures to it.

[Darksonn]

People use block_in_place from non-async functions, so it cannot be async.