So, here is a contrived example of my problem. I ...

# coroutines

[withoutclass]

So, here is a contrived example of my problem.

I am testing suspending function that returns a channel. This function sends some number of items to the channel.

If I launch the coroutine for sending items on the channel using the coroutineScope{} style of method2, sending is always suspended waiting on a receiver, but method1 does not get suspended(blocked).

As far as I can tell, both method 1 and method2 would launch using the same dispatcher (Dispatchers.IO), and that I'm not doing anything "wrong" per se, but clearly I am given I would expect method1 to not get stuck.

Coroutine_Scope_Confusion.kt

[withoutclass]

Note that if I make a new CoroutineScope(coroutineContext) in method2, the code does not block execution. If I use GlobalScope.launch(coroutineContext), the code does not block execution.

[withoutclass]

I think for now I'm going to stick with CoroutineScope(coroutineContext).launch, given it uses parent context and dispatcher without actually blocking the execution of the function launching it

[uli]

`coroutineScope`will wait for all child coroutines to finish, i.e. for send to complete. Only then will method2 return the channel.
Now send will not complete until there is a recever...

[withoutclass]

so coroutineScope will effectively block a parent coroutine from executing if a child coroutine suspends?

[withoutclass]

I guess I just need to alter how I consider scoping things. I can't utilize parent scope of a top level job to create child coroutines in a lower level service. I'll need to have separate scopes, even though I care about stopping the lower level service if my top level job get's cancels/stopped

[withoutclass]

So this particular example needs to be solved by either: 1. Not having method calls launch child coroutines using coroutineScope or 2. Providing the channel to the method call instead of having the method return a new channel

[withoutclass]

And even then I don't think option 2 would solve the issue, given the parent coroutine would be blocked unable to read from the channel due to method2 suspending

[withoutclass]

Anyways this is probably my own fault for not quite being used to the new style, thanks for the help @uli

[withoutclass]

Is it a good assumption that really, method1 and method2 should just be producers from a design perspective?