How to understand order of calling coroutines with scope? - kotlin-coroutines

I saw the coroutines example here.
To understand the example I made three different examples with each scope.
The printed number is the following #N.
It's just my opinion, so if there is a wrong thing, let me know.
#1: 3->1->2->4
runBlocking {
launch {
println("1-Task from runBlocking")
}
coroutineScope { // Creates a coroutine scope
launch {
println("2-Task from nested launch")
}
println("3-Task from coroutine scope")
}
println("4-Coroutine scope is over")
}
I understood the coroutineScope waits until the children will be completed. The outer runBlocking has two coroutines.
The first is launch of 1 and the second is in coroutineScope.
The coroutineScope will be handled first based on the call stack.
Thus the first printed number is 3 because it's within regular function.
And then the 1 can be printed before 2.
The 4 will be printed after coroutineScope block is finished.
#2: 1->3->2->4
runBlocking {
launch {
println("1-Task from runBlocking")
}
runBlocking { // Creates a coroutine scope
launch {
println("2-Task from nested launch")
}
println("3-Task from coroutine scope")
}
println("4-Coroutine scope is over")
}
runBlocking is not suspend function that's why the outer runBlocking doesn't have a coroutine. Thus the 1 will be printed first. After that, the inner runBlocking has one coroutine so wait until this block will be finished. Thus 3 and 2 will be printed. Last, 4 printed after inner runBlocking.
#3: 2->4->3->1, 4->3->2->1, 4->2->3->1
runBlocking {
launch {
println("1-Task from runBlocking")
}
GlobalScope.launch { // Creates a coroutine scope
launch {
println("2-Task from nested launch")
}
println("3-Task from coroutine scope")
}
println("4-Coroutine scope is over")
}
There are several different results so I guessed it depends on environments on runtime.
But I wonder if it's impossible to print 1 first or not.
Second, how to understand scope in other suspend or scope.

Related

what reason show message that "Possibly blocking call in non-blocking context could lead to thread starvation"?

i using coroutines with spring.
message that "Possibly blocking call in non-blocking context could lead to thread starvation" is show when this code using.
really happen blocking call ?
If happen could you tell me reason ?
Thank you.
suspend fun demo() = withContext(Dispatchers.IO) {
val deferred1 = async {
aRepository.findById("id") // here
}
val deferred2 = async {
bRepository.findById("id") // here
}
deferred1.await()
deferred2.await()
}
I'm assuming that this concerns JPA repositories, and they perform work synchronous, and were build for the servlet architecture, which uses blocking code.
Using them with (asynchronous) coroutines triggers this warning. However, I'm not entirely sure if this really is an issue per se.
A solution to suppress this warning is by wrapping the blocking code with withContext (also the provided fix-it in my intellij), which suspends the coroutine while the code within the block is executed;
suspend fun demo() = withContext(Dispatchers.IO) {
val deferred1 = async {
withContext(Dispatchers.IO) {
aRepository.findById("id") // here
}
}
val deferred2 = async {
withContext(Dispatchers.IO) {
bRepository.findById("id") // here
}
}
deferred1.await()
deferred2.await()
}

Volley doesn't respond in suspense function [duplicate]

I have a suspend function that calls POST request to the server. I want to configure some text in the activity to show the information I received from the server.
suspend fun retrieveInfo():String
I tried calling inside onCreate, onResume but crashes runtime.
runBlocking {
retrieveInfo()
}
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.google.augmentedimage/com.google.AugmentedImageActivity}: android.os.NetworkOnMainThreadException
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3086)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3229)
at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:78)
at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68)
Where am I suppose to put these suspend calls (in which part of lifecycle of activity)? Should I be using something other than runBlocking?
By default runBlocking runs the suspending code block in the thread runBlocking was called on.
So if you called runBlocking from the Activity callback your suspending block will be executed on the main thread, from which you cannot access network (query a server).
You need to switch a dispatcher in your coroutine block for that call. The simplest fix for your code would be to move the execution to the Dispatchers.IO.
runBlocking {
withContext(Dispatchers.IO) {
retrieveInfo()
}
}
That being said, I suggest two things (not related directly to your question):
Read Coroutines on Android (this part and the following ones)
2. Don't use runBlocking for your case, but define a correct job and use job.launch{}
If you want to write in activity:
class MyActivity : AppCompatActivity() {
private val scope = CoroutineScope(newSingleThreadContext("name"))
fun doSomething() {
scope.launch { ... }
}
}

How this piece of code can be improved and rewritten to kotlin coroutines

I'm trying to achieve functionality: I have a rest endpoint that calls code that execution can take a lot of time. My idea to improve experience for now is to wrap that piece of code as a new thread, wait for completion or for some max time to elapse and return an appropriate message. Wrapped code should be completed even through endpoint already send message back. Current implementation looks like this:
private const val N = 1000
private const val MAX_WAIT_TIME = 5000
#RestController
#RequestMapping("/long")
class SomeController(
val service: SomeService,
) {
private val executor = Executors.newFixedThreadPool(N)
#PostMapping
fun longEndpoint(#RequestParam("someParam") someParam: Long): ResponseEntity<String> {
val submit = executor.submit {
service.longExecution(someParam)
}
val start = System.currentTimeMillis()
while (System.currentTimeMillis() - start < MAX_WAIT_TIME) {
if (submit.isDone)
return ResponseEntity.ok("Done")
}
return ResponseEntity.ok("Check later")
}
}
First question is - waiting on while for time seems wrong, we don't release thread, can it be improved?
More important question - how to rewrite it to Kotlin coroutines?
My attempt, simple without returning as soon as task is done, looked like this:
#PostMapping
fun longEndpoint(#RequestParam("someParam") someParam: Long): ResponseEntity<String> = runBlocking {
val result = async {
withContext(Dispatchers.Default) {
service.longExecution(someParam)
}
}
delay(MAX_WAIT_TIME)
return#runBlocking ResponseEntity.ok(if(result.isCompleted) "Done" else "Check later")
}
But even through correct string is returned, answer is not send until longExecution is done. How to fix that, what am I missing? Maybe coroutines are bad application here?
There are several problems with your current coroutines attempt:
you are launching your async computation within runBlocking's scope, so the overall endpoint method will wait for child coroutines to finish, despite your attempt at return-ing before that.
delay() will always wait for MAX_WAIT_TIME even if the task is done quicker than that
(optional) you don't have to use runBlocking at all if your framework supports async controller methods (Spring WebFlux does support suspend functions in controllers)
For the first problem, remember that every time you launch a coroutine that should outlive your function, you have to use an external scope. coroutineScope or runBlocking are not appropriate in these cases because they will wait for your child coroutines to finish.
You can use the CoroutineScope() factory function to create a scope, but you need to think about the lifetime of your coroutine and when you want it cancelled. If the longExecution function has a bug and hangs forever, you don't want to leak the coroutines that call it and blow up your memory, so you should cancel those coroutines somehow. That's why you should store the scope as a variable in your class and cancel it when appropriate (when you want to give up on those operations).
For the second problem, using withTimeout is very common, but it doesn't fit your use case because you want the task to keep going even after you timeout waiting for it. One possible solution would be using select clauses to either wait until the job is done, or wait for some specified maximum time:
// TODO call scope.cancel() somewhere appropriate (when this component is not needed anymore)
val scope = CoroutineScope(Job())
#PostMapping
fun longEndpoint(#RequestParam("someParam") someParam: Long): ResponseEntity<String> {
val job = scope.launch {
longExecution()
}
val resultText = runBlocking {
select {
job.onJoin() { "Done" }
onTimeout(MAX_WAIT_TIME) { "Check later" }
}
}
return ResponseEntity.ok(resultText)
}
Note: I'm using launch instead of async because you don't seem to need the return value of longExecution here.
If you want to solve the problem #3 too, you can simply declare your handler suspend and remove runBlocking around the select:
// TODO call scope.cancel() somewhere appropriate (when this component is not needed anymore)
val scope = CoroutineScope(Job())
#PostMapping
suspend fun longEndpoint(#RequestParam("someParam") someParam: Long): ResponseEntity<String> {
val job = scope.launch {
longExecution()
}
val resultText = select {
job.onJoin() { "Done" }
onTimeout(MAX_WAIT_TIME) { "Check later" }
}
return ResponseEntity.ok(resultText)
}
Note that this requires spring-boot-starter-webflux instead of spring-boot-starter-web.
Your implementation always waits for MAX_WAIT_TIME. This might work:
#PostMapping
fun longEndpoint(#RequestParam("someParam") someParam: Long): ResponseEntity<String> = runBlocking {
try {
withTimeout(MAX_WAIT_TIME) {
async {
withContext(Dispatchers.Default) {
service.longExecution(someParam)
}
}
}
} catch (ex: CancellationException) {
return#runBlocking ResponseEntity.ok("Check later")
}
return#runBlocking ResponseEntity.ok("Done")
}
Although I'm not sure if there will be any unwanted side effects because it seems that this will cancel the coroutine when it reaches MAX_WAIT_TIME. Read more about it here:
Cancellation and timeouts

Can I call Deferred<>.await() many times?

I am newbie about coroutines and I have a simple question.
Can I call await() many times to get result value?
E.g.
class Test: CoroutineScope {
val my_value = async { "Hello World!" }
suspend fun f1() {
println(my_value.await())
}
suspend fun f2() {
println(my_value.await())
}
I suppose second call "await()" will immediately return computed value. It's right?
Tnx
You can call Deferred.await() as many times as you want/need. The result is simply returned or the exception is thrown again.

kotlin coroutines, what is the difference between coroutineScope and withContext

withContext
suspend fun <T> withContext(
context: CoroutineContext,
block: suspend CoroutineScope.() -> T
): T (source)
Calls the specified suspending block with a given coroutine context, suspends until it completes, and returns the result.
suspend fun <R> coroutineScope(
block: suspend CoroutineScope.() -> R
): R (source)
Creates a CoroutineScope and calls the specified suspend block with this scope. The provided scope inherits its coroutineContext from the outer scope, but overrides the context’s Job.
the withContext takes CoroutineContext, and both seems to be complete after all its children are complete.
In what case the withContext or the coroutineScope should be preferred than the other?
for example:
suspend fun processAllPages() = withContext(Dispatchers.IO) {
// withContext waits for all children coroutines
launch { processPages(urls, collection) }
launch { processPages(urls, collection2) }
launch { processPages(urls, collection3) }
}
could also be
suspend fun processAllPages() = coroutineScope {
// coroutineScope waits for all children coroutines
launch { processPages(urls, collection) }
launch { processPages(urls, collection2) }
launch { processPages(urls, collection3) }
}
are the both processAllPages() doing the same?
update: see discuss at Why does withContext await for the completion of child coroutines
Formally, coroutineScope is a special case of withContext where you pass in the current context, avoiding any context switching. Schematically speaking,
coroutineScope ≡ withContext(this.coroutineContext)
Since switching contexts is just one of several features of withContext, this is a legitimate use case. withContext waits for all the coroutines you start within the block to complete. If any of them fail, it will automatically cancel all the other coroutines and the whole block will throw an exception, but won't automatically cancel the coroutine you're calling it from.
Whenever you need these features without needing to switch contexts, you should always prefer coroutineScope because it signals your intent much more clearly.
coroutineScope is about the scoped lifecycle of several sub-coroutines. It's used to decompose a task into several concurrent subtasks. You can't change the context with it, so it inherits the Dispatcher from the current context. Typically each sub-coroutine will specify a different Dispatcher if needed.
withContext is not typically used to start sub-coroutines, but to temporarily switch the context for the current coroutine. It should complete as soon as its code block completes (as of version 1.3.2, this is actually still stated in its documentation). Its primary use case is offloading a long operation from the event loop thread (such as the main GUI thread) to a Dispatcher that uses its own thread pool. Another use case is defining a "critical section" within which the coroutine won't react to cancellation requests.

Resources