I'm a bit confused by the new scoping mechanism. I'm trying to migrate some coroutine-based code and...

# coroutines

[uhe]

I'm a bit confused by the new scoping mechanism. I'm trying to migrate some coroutine-based code and stumbled upon this:

@Deprecated("No replacement. Group child in a coroutineScope { } block to wait for them")
public suspend fun Job.joinChildren()

However, I don't see how to "group child in a coroutineScope".

For example:

val networkContext = <http://Dispatchers.IO|Dispatchers.IO>
val networkJob = Job()

private fun onNetworkContext(block: suspend CoroutineScope.() -> Unit) =
    GlobalScope.launch(networkContext + networkJob, block = block)

// invoked from another coroutine:
suspend fun abortAndRetry() {
    networkJob.cancelChildren()
    // how do I replace this properly?
    networkJob.joinChildren()
   // retry ...
 }

[Jonathan]

Depends a but on what you're doing, but the concept is roughly:

var networkScope = CoroutineScope(Job() + <http://Dispatchers.IO|Dispatchers.IO>)

private fun onNetworkContext(block: suspend CoroutineScope.() -> Unit) =
    networkScope.launch(block = block)

// invoked from another coroutine:
suspend fun abortAndRetry() {
  networkScope.coroutineContext[Job]?.cancelAndJoin()
  
  // retry ...
  networkScope = CoroutineScope(Job() + <http://Dispatchers.IO|Dispatchers.IO>)
}

[Jonathan]

The key point is to not use GlobalScope if you want to manage the life cycle of child jobs.

[elizarov]

An interesting use-case. Can you give more details on why exactly you need to separate onNetworkContext and abortAndRetry? I would be grateful if you create an issue in <http://github.com/kotlin/kotlinx.coroutines/issues> so that we can have a discussion here.

[elizarov]

Maybe we were too fast to deprecate joinChildren, but let’s see if the use-case is strong enough.

[elizarov]

Anyway, it is extremely easy to write:

networkJob.children().forEach { it.join() }

[elizarov]

But beware, the reason that it is deprecated is because you have a race in your code. Nothing prevents a new child to be added between cancelChildren and joinChildren. So, I strongly suggest to rewrite this code via networkJob.cancelAndJoin and then create a new (non-cancelled) parent job for all further children

[uhe]

I guess my scenario is a bit weird

[elizarov]

The code that uses joinChildren in inherently racy

[uhe]

I'm basically bridging events to coroutines, e.g. I receive events, handle them on a singlethreaded event coroutine context and launch other network-related coroutines from within the event context

[uhe]

I'll think about this some more and maybe create an issue like you suggested tomorrow