Watching the <new video on kotlin coroutines 1.5> - I’m a little confused by the description of the ...

# coroutines

[spierce7]

Watching the

new video on kotlin coroutines 1.5▾

- I’m a little confused by the description of the GlobalScope delicate api legitimate use cases.

It’s my understanding that any time I would create a generic CoroutineScope , and then not cancel it, I can use GlobalScope instead. Is that correct? The main hesitation with the GlobalScope is simply that you can’t cancel it, and thus, it doesn’t lend itself well to hierarchical coroutines, right?.

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

There’s never a good reason to use GlobalScope in real, production code. The alternatives are always better.

[spierce7]

So lets say that I receive a push message in a service, and I want to send the push message to be handled to the PushMessageRepository. I don’t want to cancel the handling of the push message under any circumstances (I don’t think?).

I would normally call:

GlobalScope.launch {
    pushMessageRepository.handleMessage(message)
}

Instead, what should I do, and how does it produce different results?

[streetsofboston]

@Zach Klippenstein (he/him) [MOD] I agree that it's 99% of the time, but why "always"...?

If you have an object (singleton?) with a truly global lifecycle, ie it stays alive until the process ends, the use of GlobalScope if fine. What would be the advantage of creating your own non-cancalleble CoroutineScope?

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

Because as soon as you want to customize the dispatcher, or any other aspect of the default context for your global scope, you’ll just create a custom scope anyway. That has virtually no extra boilerplate. There’s no reason for GlobalScope to exist. It causes tons of problems, and solves none.

[steamstreet]

I would also love to know the answer of how to craft alternatives, but there’s a lot more “Don’t use GlobalScope” and not much “Here’s what you should use”.

[streetsofboston]

🙂
And, since GlobalScope is still there and not deprecated, when can/should you (still) use GlobalScope?

[steamstreet]

I’ll be more specific… I’m using a browser library, lots of callbacks. I’m wrapping it so that I can handle those callbacks asynchronously. So that callback function is not able to be a suspend function, I have to use a scope, and I’m just not seeing examples of how I’m supposed to do this.

[steamstreet]

almost all of the examples are;

GlobalScope.launch { callback() }

[steamstreet]

Here’s an example from StackOverflow: https://stackoverflow.com/questions/63607484/kotlin-js-suspension-function-in-an-htmlbuttonelement-eventlistener where the only answer is GlobalScope.launch

[spierce7]

@Zach Klippenstein (he/him) [MOD]

Because as soon as you want to customize the dispatcher, or any other aspect of the default context for your global scope, you’ll just create a custom scope anyway

But when you are using a member variable, you have to remember to create it as a SupervisorJob, as Job isn’t what you actually want most of the time in those cases.

[spierce7]

Whenever I want a custom dispatcher for that use case, I just do GlobalScope + Dispatchers.Main. This isn’t a performance thing, it’s a convenience thing.