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

thana

08/04/2019, 11:22 AM
i just stumbled across this sentence in the
coroutineContext
documentation "By convention, should contain an instance of a job to enforce structured concurrency.". What does it mean? It'spossible that a context does NOT contain a job? what are the consequences if a job instance is missing?
d

Dominaezzz

08/04/2019, 11:31 AM
I haven't checked but maybe when you use
suspend fun main(args: Array<String>)
.
Since you don't need to use
kotlinx.coroutines
for that and that's where
Job
comes from.
If
Job
is missing, cancellation can't happen. (I'm not sure if I should say "easily" or "not at all" here).
m

Marko Mitic

08/04/2019, 12:00 PM
Dominic is up 24/7 ready to help
d

Dominaezzz

08/04/2019, 12:02 PM
😅
g

gildor

08/04/2019, 1:49 PM
Just want to add that it's not related on
suspend main
, because it doesn't have scope so not related to structured concurrency and scopes, this convention only about coroutine scopes implementation, because if it doesn't have Job, it doesn't have child/parent relationship and cannot be cancelled
d

Dico

08/04/2019, 4:34 PM
Yeah, suspend main runs a simple event loop, that's it
When kotlinx coroutines isn't present, there is no job to speak of unless someone made their own library
But CoroutineContext is part of stdlib, not kotlinx
t

thana

08/05/2019, 5:40 AM
Ahh, so the Job is the thing that makes structured concurrency really possible but is introduced by the extension only?
g

gildor

08/05/2019, 5:42 AM
the extension?
t

thana

08/05/2019, 5:42 AM
sorry, i mean kontlinx.coroutine
g

gildor

08/05/2019, 5:42 AM
Coroutines cancellation, Job, Structured Concurrence, CoroutineScope all those things are library features of kotlinx.coroutine, it’s not a part of the language
But suspend function and CoroutineContext is part of the language
t

thana

08/05/2019, 5:44 AM
so basically the "native" parts are much like java's
Thread
from a structuring point of view?
g

gildor

08/05/2019, 5:44 AM
not sure how it’s comparable
t

thana

08/05/2019, 5:44 AM
A
Thread
is basically fire and forget
g

gildor

08/05/2019, 5:45 AM
See, this is whole coroutines API that available in the language and stdlib https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.coroutines/index.html
No
because suspend function is not fire and forget, it always returns value or throws exception
it just don’t have cancellation, which has own semantics and just based on the primitives provided by the language
t

thana

08/05/2019, 5:53 AM
now i do interpret the essence of structured concurreny is being able to cancle a coroutine or a coroutine scope... but i feel this is wrong 🤔
'm really having problems wrapping my head arund coroutines and structured concurrency 😞
g

gildor

08/05/2019, 5:54 AM
see, you need structured concurrency when you have some background or parallel work, like async/launch, right?
t

thana

08/05/2019, 5:55 AM
yes!
g

gildor

08/05/2019, 5:55 AM
so, because there is no way to start background coroutine, async and launch do not exist in stdlib, than no probblem %)
t

thana

08/05/2019, 5:55 AM
and managing threads has aways been PITA
g

gildor

08/05/2019, 5:55 AM
coroutines has nothing to do with managing threads by itself
t

thana

08/05/2019, 5:56 AM
ywah but that's what you have to do in java 🙂
g

gildor

08/05/2019, 5:56 AM
this is just a feature of kotlinx.coroutines which provides dispatcher API
t

thana

08/05/2019, 5:57 AM
how would we use coroutines on a world without kotlinx.coroutines? what would be there use?
oh sequences are part of the stdlib
g

gildor

08/05/2019, 5:58 AM
ywah but that’s what you have to do in java
not sure what you mean. See, coroutines by itself and their basic primitives in stdlib has nothing to do with threading, it’s language feature to simplify writing asynchronous code in a sequential style, that’s all, it provides you primitives to convert callback to suspend fucntion Threading, cancellation, scopes, async, launch etc are features of kotlinx.coroutines library which provides high level primitves based on Kotlin Coroutines
how would we use coroutines on a world without kotlinx.coroutines? what would be there use?
They are pretty low level, and this is whole point of them. For example #arrow (and some other libraries) use coroutines but do not use kotlinx.coroutines Again, it’s just primitives used by other libraries
t

thana

08/05/2019, 5:59 AM
you are right - i should really change my view on coroutines. i alway fall back to the concurrency-and-multithreading-viewl
g

gildor

08/05/2019, 6:04 AM
how would we use coroutines on a world without kotlinx.coroutines? what would be there use?
Just a very simple example, which has nothing to do with threading or cancellation. Imagine you have this asynchronous API:
Copy code
fun <T> sendRequest(onSuccess: (T) -> Unit, onError: (Throwable) -> Unit) {
    TODO()
}
so you can see how to use it, do something in onSuccess or onError, but if you have nested calls or you have some more complicated behavior you have all usual async programming probblems
now you convert it to suspend function without dependency on kotlinx.coroutines:
Copy code
suspend fun <T> awaitRequest(): T {
    return suspendCoroutine { cont ->
        sendRequest<T>(
                onSuccess = { cont.resume(it) },
                onError = { cont.resumeWithException(it) }
        )
    }
}
and use it with suspend main:
Copy code
suspend fun main() {
    val result = awaitRequest<T>()
    println(result)
}
See, no callbacks, no, nesting, only stdlib APIs
also no cancellation, but it’s the same as original, callback based, API
t

thana

08/05/2019, 6:09 AM
i see, thank you very much 🙂
Since the initial rollout of Kotlin coroutines as an experimental feature in Kotlin 1.1 in the beginning of 2017 we’ve been working hard to explain the concept of coroutines to the programmers who used to think of concurrency in terms of threads, so our key analogy and motto was “coroutines are light-weight threads”.
i think that's why i always think about threads when i think about coroutines 😉
g

gildor

08/05/2019, 6:11 AM
yes, and it’s covered by kotlinx.coroutines, which has own “light-weight thread” implementation based on coroutines
t

thana

08/05/2019, 6:12 AM
well, i think roman talks about coroutines in context of the stdlib here... it's hard to see a didfference here, when you are new to coroutines 😕
g

gildor

08/05/2019, 6:13 AM
no need to see difference, just use kotlinx.coroutines %) This is the way to use them, especially if you just started
t

thana

08/05/2019, 6:14 AM
😄
g

gildor

08/05/2019, 6:14 AM
stdlib coroutines just too low level for every day usage, and more like a primitive for library authors
The main thing that you should understand what is suspend function
t

thana

08/05/2019, 6:14 AM
but then again i come back to my kind of initial question: why are `Job`s the crucial point in applying structured concurrency?
https://medium.com/@elizarov/structured-concurrency-722d765aa952 e.g. doesn't even mention Jobs, yet on almost every api the has to do with
CoroutineScope
or
coroutineContext
it's written that any context should contain a job to enforce structured concurrency
g

gildor

08/05/2019, 6:17 AM
Strucutred concurrency is just approach to management of asynchronous background task lifecycle. To manage lifecycle (aka cancel it when task is not needed anymore to free resources, avoid leaks etc) you need some abstraction for cancellation. And Job is this abstraction. You have (in simplest and most common case) 1 Job per Scope, this job become parent for all child coroutines launched from this scope, and when you cancel scope all child coroutines are also cancelled
Note that an implementation of CoroutineScope also defines an appropriate coroutine context for your UI updates. You can find a full-blown example of CoroutineScope implementation on its documentation page.
https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-coroutine-scope/index.html
it’s just simple introduction, mostly focused on use case with parallel decomposition, where you don’t need to work with Job directly
it’s written that any context should contain a job to enforce structured concurrency
So, I don’t see contradiction here
t

thana

08/05/2019, 6:21 AM
ok.. i think i start to grasp it... from the beginning coroutines have had a more or less well defined scope they live in, but cancellation was the missing piece at least when it comes to longer running backround tasks that we might or might not want to cancel at some point in time?
g

gildor

08/05/2019, 6:24 AM
StructuredConcurrency just designed in a way when you can run background task only in some scope (it can be global, but you have to be explicit about it and use
GlobalScope.launch
), and this scope can be cancelled
Imagine if you need scope for every started thread, like you cannot start a new thread without ThreadPool, it’s essenttially the same. Than to stop all threads you just cancel thread pool
t

thana

08/05/2019, 6:25 AM
but the scope can only be canceled if its context contains a
Job
, right?
g

gildor

08/05/2019, 6:25 AM
That is the thing, you cannot cancel scope by itself
it’s just an interface with
coroutineContext
property
But there is extension function
CoroutineScope.cancel()
just check what it does
So scope cancellation is just a convention
t

thana

08/05/2019, 6:28 AM
error("Scope cannot be cancelled because it does not have a job: $this")
ha
so maybe finally my understanding allows me to make correct assumptions 😄
thank you very much, @gildor i have much to think about now 🙂
👍 1
2 Views