is `GlobalScope` considered bad practice, what is the specific use case of it?

# coroutines

[Tuan Kiet]

is GlobalScope considered bad practice, what is the specific use case of it?

[gildor]

When you really need global background state

[gildor]

Also for some adapters, like for RxJava, where you just want to delegate lifecycle management to subscriber

[uhe]

I really, really don't think that using GlobalScope can always be considered bad practice.

[gildor]

In most of cases it is

[uhe]

Is there a list of "most of cases" that I can check?

[gildor]

just checking with our code base

[uhe]

I'm asking this because most of the official examples that I have seen that advocate structured concurrency are tied to very specific use cases.

[gildor]

I disagree

[gildor]

why they are specific?

[gildor]

we now even injecting scope for top level global tasks, which before were just global, now has user session lifecycle

[uhe]

Specific in a way that prevents me from applying them in my contexts

[uhe]

Maybe that's just me, though. Sorry for derailing the discussion.

[gildor]

What is your context? Do you have an example?

[Antanas A.]

It's considered bad practices because you cannot control that run in your test suites

[Antanas A.]

Haven't worked for us, and every time we've converted GlobalScope.launch call into explicitlyPassedScope.launch { }

[Antanas A.]

for example you cannot simulate time line in tests so code with some delay(...) calls cannot be tested fast

[uhe]

Can't you use https://github.com/Kotlin/kotlinx.coroutines/tree/master/kotlinx-coroutines-test#testing-launch-or-async-with-delay for that? (haven't tested it myself)

[uhe]

Also, you can still change the dispatcher / job that you pass to GlobalScope.launch in your tests

[gildor]

It’s considered bad practices because you cannot control that run in your test suites

I think it’s wrong assumption.
It’s bad practice because it’s global background job whicch should be explicitly handled and in most cases it may be avoided

And yeah test such side effects is also probably bad practice by itself, better to test suspend functions

[gildor]

for example you cannot simulate time line in tests so code with some delay(...) calls cannot be tested fast

You still can inject custom context to launch, it has nothing to do with GlobalScope, it’s the same as with any other scope

[streetsofboston]

For testability, we inject the scope on which an instance ('s launches) run, at runtime. That allows us to inject a testCoroutineScope when running unit-tests.

Even during injection, we don't often inject GlobalScope, and inject CoroutineScope(someJob + someDispatcher) instead.