Imagine I have a Spring WebFlux controller implemented with Kotlin that looks something like this:
@RestController
@RequestMapping("/api/foo")
class MyController {
@GetMapping
suspend fun getFoo(): FooResource {
return withContext(Dispatchers.IO) {
// fetch some resource with some expensive blocking IO call
}
}
}
The way I understand WebFlux's concurrency model, there is only one thread available to handle requests, so if I for some reason can't avoid blocking IO calls, I need to somehow offload it to another thread. The kotlinx.coroutines.withContext helper supposedly does exactly that, with the IO dispatcher being specifically designed for such a use case.`I have seen this pattern at several blog posts, so it appears to be common wisdom.
However, [the documentation on Dispatchers.IO says:
This dispatcher shares threads with a Default dispatcher, so using withContext(Dispatchers.IO) { ... } does not lead to an actual switching to another thread — typically execution continues in the same thread. As a result of thread sharing, more than 64 (default parallelism) threads can be created (but not used) during operations over IO dispatcher.
So that leaves me wondering: If WebFlux only uses a single "main thread" for handling requests, and blocking IO might still happen in this thread even if I'm using withContext(Dispatchers.IO): Is this pattern safe to use, and if not, what else should I do?