Hi! I saw around a bunch of example where suspending function gets defined with coroutineScope like in

suspend fun myFun() = coroutineScope {}

I wonder, given that a suspending function must be called within a scope, what’s the point of creating a new scope like in there?

it creates a "child" scope, so that all work started by that function must complete before that function returns (unless you explicitly use another scope)

gotcha, so that means that if I have those 2 snippets

suspend fun myFun() = coroutineScope {
    launch { timeExpensiveFun() }
}

and

suspend fun myFun() =
    launch { timeExpensiveFun() }

the second function will return while launch will still be in progress, while in the first case myFun will wait for launch to be completed. Is that right? If this is the case would it be right to say that in my code I can use coroutineScope {} when I need to bridge sync and async world instead of runBlocking{} ?

the second one won't work in current coroutine land

how come?

launch

is defined as an extension of

CoroutineScope

, i.e.

fun CoroutineScope.launch

sorry you’re right, I meant something like

suspend fun myFun() =
    scope.launch { timeExpensiveFun() }

on the original question: the first one will wait you cannot use

coroutineScope

to bridge sync and async as it itself is

suspend

, but

runBlocking

already provides you with a

CoroutineScope

inside it just like

coroutineScope

got it, yeah sorry I’m still in trouble trying to understand when to use suspend 🙂

generally, use it when you need it 🙂 the compiler will tell you if you do

so just to make an example, say you have a class when you want to call different apis (and don’t mind about the results). Would you do something like this:

fun callAllGuys() {
  private val scope = CoroutineScope(Executors.newFixedThreadPool(2).asCoroutineDispatcher())
  for (website in websites) {
      scope.launch(callWebsiteLambda())
  }
}

or do you think that’s wrong and there is a better example with structured concurrency?

You would probably define the scope as a class property instead, so that you can cancel the scope when the class is disposed/cancelled/shutdown whenever your architecture is done with it. And don't create a new thread pool, one of the advantages of using coroutines is that you get a high level of concurrency without allocating more threads. So something like this:

class YourApiWrapper {
  private val scope = CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO>)

  fun callAllApis() {
    for (website in websites) {
      scope.launch { … }
    }
  }

  fun shutdown () {
    scope.cancel()
  }
}