I've got some suspend functions that do background IO. In some cases, I just need to fork them off t...

# coroutines

[Travis Griggs]

I've got some suspend functions that do background IO. In some cases, I just need to fork them off to run in the background, and when that's the case, I've just been using:

CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO>).launch { runTheSuspendFunction() }

But I was reading the documentation and saw this line in there:

Manual implementation of this interface is not recommended, implementation by delegation should be preferred instead.

Which leads me to ask... am I doing something I ought not? Is there a more preferred way to do this?

[kevin.cianfarini]

yes. This breaks structured concurrency. If the thing which is launching this task gets cancelled then you have no way to automatically cancel runTheSuspendFunction.

Rather than pulling a coroutine scope out of thin air like you’re doing, you should:

class SomeThing {
  val scope = CoroutineScope(...)
 
  fun runFunctionAsync() {
    scope.launch(<http://Dispatchers.IO|Dispatchers.IO>) { runTheSuspendFunction() }
  }

  fun close() = scope.cancel()
}

[kevin.cianfarini]

In general a coroutine scope should always be tied to some lifecycle. That could the the lifetime of a stack frame, the lifetime of an object which offers resource cleanup (close), or the lifetime of platform thing like a ViewModel or a compose effect.