GlobalScope

is getting guard rails! My dream come true 😌

I know

GlobalScope

usage is discouraged, but I think it's hard to avoid it when developing on Kotlin/JS. Most of the time there is just no better/easier way to launch coroutines. Of course I can create another singleton object instead, but for me it just doesn't make sense.

🤣 congrats! Honest question regarding

GlobalScope

, while I agree that it should never be used, would it be better to use a new scope that is never canceled for tasks that need to run once in a coroutine, or run it in the global scope? For example, on an Android project, I have a specific job I want to run once, and don't need any result back. It can take the entire app process lifecycle (if it is short) or run until completion.

Firstly, even if you are using

GlobalScope

, you shouldn’t hard-code it – you should inject it and provide it from a module near the root of your DI graph. Then, it’s still not a bad idea to make your own scope, because you can set the dispatcher explicitly, instead of having to remember what dispatcher

GlobalScope

happens to use.

I have an

AppScope

in real world projects

Firstly, even if you are using 

GlobalScope

, you shouldn’t hard-code it – you should inject it and provide it from a module near the root of your DI graph.

Why so? Isn't injecting a dispatcher sufficient?

These are some good suggestions. I am iffy on adding GlobalScope to the DI graph, as I can see that being abused. We are pushing to ensure all scopes are created with the main dispatcher, so having one that isn't would break trust. Having an AppScope that follows our paradigm in the DI graph might be the better option, but then the same lifecycle problems with global scope would exist in this app scope... Might revisit some code tomorrow to see what would become our best practice for this.

If your

AppScope

has a

Job

inside, it's safer than

GlobalScope

.

Yea, I wouldn’t use global scope even when it’s injected (your example, using the main dispatcher for all coroutines by default instead of Default, is a great reason), but the point is that if it is injected, none of your code actually has to know or care what that root coroutine scope actually is, and changing it to a different scope is trivial.

@Robert Jaros I am actively developing in Kotlin/JS (browser) and I never have to use

GlobalScope

at all, I just

CoroutineScope(window.asCoroutineDispatcher()).launch {
  // do things here
}

I think there is a Kotlin/JS(node) way of getting a dispatcher scoped to the process

Is there any significant difference between using above and the

GlobalScope

on JS?

@Robert Jaros https://kotlinlang.slack.com/archives/C1CFAFJSK/p1619510335139900?thread_ts=1619479829.137200&cid=C1CFAFJSK

What does "safer" mean?

Not subject to this kind of issues: https://youtrack.jetbrains.com/issue/KT-30588 https://github.com/Kotlin/kotlinx.coroutines/issues/2557

Do I understand correctly that we should always keep the reference to the CoroutineScope?

Yes

So the way proposed by @andylamax (

CoroutineScope(window.asCoroutineDispatcher()).launch { }

) is still not safe enough?

You need to keep a reference to the

CoroutineScope

or to the

Job

returned by

launch

or it will be garbage collected whenever there's no strong reference held and the coroutine is suspended.

I think it should be more clearly stated in the documentation here: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-coroutine-scope/, because it doesn't mention the GC problem.

That'd be an issue to raise on GitHub

With

GlobalScope

"gone" 😉 the documentation on creating custom scopes the right way (with all this important information) should be somewhere in the main docs here https://github.com/Kotlin/kotlinx.coroutines

So, for

JS

something like

val scope = CoroutineScope(window.asCoroutineDispatcher())

scope.launch {
  // do stuff here
}

works?

This thread has been great insight on some of the minor nuances of Coroutines, especially when it comes to using

GlobalScope

. Thanks @louiscad for the insight on the ticket and explanation in ensuring a strong reference to a job is kept.

What about injecting scope vs. letting the class own its scope?

@AppScope
1. class MessageSender() : HasLifecycle {
	private val scope = SuperviserScope(...)

	fun sendMessage() {
		scope.launch {
			doSendMessage()
		}
	}

	private suspend fun doSendMessage() {
		...
	}

	override fun destroy() {
		scope.cancel()
	}
}

@AppScope
2. class MessageSender(scope: coroutineScope) {

	fun sendMessage() {
		scope.launch {
			doSendMessage()
		}
	}

	private suspend fun doSendMessage() {
		...
	}
}

any reasons for one over the other?

It's not the topic of this thread FYI.