Structured Concurrency in Practice: CoroutineScope vs StructuredTaskScope [Part 4]
This post series assumes familiarity with Kotlin, Java, and Spring Boot. No AI was used during the writing of this post series. Coroutines are an all-in feature In Part 3 we finally got to a fully ...
![Structured Concurrency in Practice: CoroutineScope vs StructuredTaskScope [Part 4]](https://media2.dev.to/dynamic/image/width=1200,height=627,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fbvog4io9rpmg70ju4yvv.jpg)
Source: DEV Community
This post series assumes familiarity with Kotlin, Java, and Spring Boot. No AI was used during the writing of this post series. Coroutines are an all-in feature In Part 3 we finally got to a fully working solution, covering all the edge cases. However, we went to some trouble to get there and we had to be extra careful not to miss some of those edge cases. Some of this trouble is due to the fact we were mixing blocking and non-blocking code. Coroutines are by their nature non-blocking and they are invasive. This means that they tend to spread through the codebase. You mark one function with suspend and then you have to mark all the callers of that function with suspend, and then all the callers of all those functions, and it propagates all the way. This is why coroutines are an all-in feature. They mostly make sense if the entire codebase is non-blocking and is using coroutines. All we wanted was 2 calls in parallel In Part 1, all we wanted to achieve was to execute 2 functions concurr