is there a way to force `withContext(<http://Dispatchers.IO|Dispatchers.IO>)` onto a new thread? ap...

# coroutines

[vineethraj49]

is there a way to force withContext(<http://Dispatchers.IO|Dispatchers.IO>) onto a new thread?

applies to GlobalScope.future(<http://Dispatchers.IO|Dispatchers.IO>) etc as well

[Zach Klippenstein (he/him) [MOD]]

Why do you need to?

[vineethraj49]

hmmm

assume I have 4 default dispatcher workers; and I ended up making a blocking call on all of them like CompletableFuture.get()

DefaultDispatcher-worker-1
.get()
DefaultDispatcher-worker-2
.get()
DefaultDispatcher-worker-3
.get()
DefaultDispatcher-worker-4
.get()

now unfortunately, due to "reasons", these completablefutures are from GlobalScope.future(<http://Dispatchers.IO|Dispatchers.IO>) { }

and none of these can spawn because <http://Dispatchers.IO|Dispatchers.IO> should not context switch, but because all DefaultDispatcher-workers are blocked, there's a deadlock

there are obviously better and correct-er ways of fixing this; but out of curiosity, if <http://Dispatchers.IO|Dispatchers.IO> spawn wasn't blocked on Dispatchers.Default this could probably be avoided

[rocketraman]

Don't make blocking calls like CompletableFuture.get() on the default dispatcher. Use the suspending await extension for `CompletableFuture`: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-jdk8/.

[vineethraj49]

well, duh. but that's not what this question's about.

[elizarov]

There's no way to force a context switch here. You can try to avoid deadlock by creating a separate dispatcher with its own pool of threads, but, of course, writing code so that it is not deadlock-prone in the first place is better.

[vineethraj49]

I know this seems like an XY problem at first, but this is bad and botched attempts at mingling blocking and non-blocking code that has accumulated over two years; and there's no way to identify or fix all of it at once.

thanks for clearing that up, I will look into putting these on a separate dispatcher apart from fixing the obvious instances of blocking calls on a non-blocking context.

[rocketraman]

Have you tried using Blockhound to identify the blocking calls? https://github.com/reactor/BlockHound. Coroutines integration via kotlinx-coroutines-debug: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-debug/.