is ```GlobalScope launch Dispatchers Unconfined coroutineSco

Question

is ```GlobalScope launch Dispatchers Unconfined coroutineScope ``` a good way to use structured concurrency in an async handler that does not know about coroutines

Zach Klippenstein (he/him) [MOD] · Answer

GlobalScope is never good for anything Create a scope object use that then cancel the scope when the owner gets disposed shutdown

Zach Klippenstein (he/him) [MOD] · Answer

Also you don t need coroutineScope inside a launch the receiver is already the launched coroutine s scope

christophsturm · Answer

ok that makes sense I put the `coroutineScope`there because i wanted to go from the unstructured concurrency of GlobalScope to a local scope that ends when the block ends Is there no way to have create a block that has a local scope that ends at the end of the block ``` launch Dispatchers Unconfined do stuff scope should end here ```

christophsturm · Answer

I now did it like this <https github com christophsturm restaurant blob 313d5a07955f65362bc61a74374608b6b29690d4 src main kotlin restaurant Restaurant kt L97 L114>

christophsturm · Answer

so in shortened code ``` val requestScope = CoroutineScope Dispatchers Unconfined exchange addExchangeCompleteListener requestScope cancel requestScope launch ```

Zach Klippenstein (he/him) [MOD] · Answer

gt Is there no way to have create a block that has a local scope that ends at the end of the block All the standard coroutine builders `launch` `async` `runBlocking` etc already do that Remember `CoroutineScope` is just syntactic sugar around a `CoroutineContext` which is just a map and structured concurrency is implemented via the `Job` stored in the context Whenever you create a new coroutine it gets its own `Job` and that `Job` is stored in the context wrapped by the scope that is the receiver to the block passed to them

Zach Klippenstein (he/him) [MOD] · Answer

The problem with that solution is you re still potentially leaking coroutines you re creating your own scope but you re never cancelling it In the network request case it looks like your HttpHandlers or something above them should define the scope and pass it down and then be responsible for cancelling it whenever they are disposed

christophsturm · Answer

I m canceling it when the exchange finishes = gt at the end of the http response ```exchange addExchangeCompleteListener requestScope cancel ```

christophsturm · Answer

All the standard coroutine builders `launch` `async` `runBlocking` etc already do that lt = even when invoked on global scope

Zach Klippenstein (he/him) [MOD] · Answer

```parentScope launch childScope = this ``` `childScope coroutineContext job` will always be a child of `parentScope coroutineContext job` even if `parentScope` happens to be `GlobalScope` This is what makes structured concurrency work Technically `GlobalScope` doesn t actually have a Job I believe in which case `childScope coroutineContext job` is actually a root job but that is effectively the same as if `GlobalScope` did have a job that was just never cancelled

christophsturm · Answer

Ah you are Right that makes sense

christophsturm · Answer

But in the end it seems to be the right thing to manually create a scope and cancel it when the http response is finished

Zach Klippenstein (he/him) [MOD] · Answer

You don t need to cancel it if it completes normally The reason for cancelling it is if the thing that did the request is going away and will never use the response

christophsturm · Answer

Is it bad to always cancel it or is it just a no op when it s already finished

louiscad · Answer

no op

Zach Klippenstein (he/him) [MOD] · Answer

Not only is it not bad it s a best practice to always cancel

christophsturm · Answer

cool thanks guys