https://kotlinlang.org logo
#coroutines
Title
# coroutines
h

Harun

10/31/2018, 10:34 AM
Before migrating from coroutines experimental, i was able to use the launch as in the above snippet. Trying to do the same on Kotlin 1.3 and am not able. What am i missing?
g

gildor

10/31/2018, 10:34 AM
You missed migration to structured concurrency
direct replacement for standalone launch would be
GlobalScope.launch
h

Harun

10/31/2018, 10:42 AM
Was reading about GlobalScope.launch on ,its not recommended since it will tie the lifecycle of your coroutine to the whole application
g

gildor

10/31/2018, 10:44 AM
correct
same as old standalone launch
but looks that you manage lifecycle manually using field with Job instance
so should be fine for you
there is no difference comapring to old standalone implementation
but in general better to migrate to CoroutineScope for you component
g

gotoOla

10/31/2018, 10:47 AM
When it comes to backend services that are running within a docker container (e.g. one JVM per docker container with one app running in it) is there any benefit in creating a coroutineScope vs running Globally?
h

Harun

10/31/2018, 10:47 AM
Yeah using it in a view model so that when the view model is destroyed i cancel the job
g

gotoOla

10/31/2018, 10:47 AM
if the Services that are running in the app are singletons (i.e. the lifetime of the services is the same lifetime as the applications)
h

Harun

10/31/2018, 10:50 AM
The problem i had with coroutineScope is that it requires to be called from a suspending function
g

gildor

10/31/2018, 10:55 AM
When it comes to backend services that are running within a docker container
It’s not related to docker or type of your hardware. It depends only on coroutine lifecycle. Even for BE it make sense to limit lifecycle of coroutine in some cases, like coroutine has request lifecycle If all your coroutines are global and should be stopped only when app is killed than no, no difference, use global ones
The problem i had with coroutineScope is that it requires to be called from a suspending function
I don’t understand what is your problem. Sure, you need it only in suspend function because this block is suspend while running child coroutines. You can create instance of scope using constructor instead if you want. But you don’t need it if you have some lifecycle-aware component (like Android Activity/Fragment/ViewModel) Anyway. check guides and examples first, they should answer on most of you questions
h

Harun

10/31/2018, 11:00 AM
Okay thanks alot for the clarification
a

acando86

11/01/2018, 10:12 AM
In regard of whether structured concurrency is relevant for backend development or not, my way to visualise structured concurrency in general (please correct me if i'm wrong) is that it's not just a way to confine/delimit the overall scope of coroutines within the lifecycle of a part of your application , but it's really a way to properly structured nested coroutines all the way down in some sort of parent - child relationship. It's not just a matter of - let's say - release your coroutines resource when a screen or android activity is destroyed (that's something that was doable before manually to some extend by keeping a reference to the job when invoking launch(..) and cancelling) , it's more a way to systematically organise coroutines in some hierarchy so they are aware of their scope and they know how to properly behave for example when an exception occurs or in case some cancellation is triggered (a typical example here being parallel execution using async/await or equivalent statements)
👍 2
3 Views