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

julioyg

04/23/2018, 1:55 PM
@gildor I've just come up with your lib and wonder, how you'd cancel a request when the coroutine get's cancelled? (sorry for the ping but the most similar scenario that comes to mi mind is that you launch a network call within a coroutine and cancel it, but it wouldn't cancel the request, would it?)
g

gildor

04/23/2018, 1:58 PM
@julioyg Hi Julio, it is. Request will be cancelled after coroutine cancellation
j

julioyg

04/23/2018, 2:03 PM
thanks, I was doing that and it's not working, then must be me doing something wrong
i

igorvd

04/23/2018, 2:03 PM
Hello, can you explain to me what's the difference from wrapping the retrofit's callback with the coroutines instead of just do the blocking request and use it with something like:
Copy code
async {  call.execute() }.await()
j

julioyg

04/23/2018, 2:11 PM
@gildor
Copy code
However, when this Job is not backed by a coroutine, like CompletableDeferred or CancellableContinuation (both of which do not posses a cancelling state), then the value of onCancelling parameter is ignored.
does that mean that code inside your
registerOnCompletion
won't be executed until the request finishes?
g

gildor

04/23/2018, 2:12 PM
@igorvd Your code is blocking. I really not recommend to do request like that. Because you block thread of CommonPool, it's default thread dispatcher, so you can block all the threads and all coroutines will wait your network requests
@igorvd my lib uses async API of retrofit and do not lock additional threads and uses default threading strategy of okhttp If you provide a separate coroutine dispatcher it will be close to what my adapter does, but okhttp strategy more complicated than fixed thread pool You can check default implementation here: https://github.com/square/okhttp/blob/master/okhttp/src/main/java/okhttp3/Dispatcher.java#L40
@igorvd Because okhttp is not really non-blocking, it uses thread pool under the hood, there is no significant difference (you cannot emulate easily requests per host and similar strategies using custom dispatcher, but this is not critical in many cases). But for other "true" non blocking libraries, that based on Java NIO or something similar, approach with callback adapter can be significantly better than usage of blocking API
@julioyg let me check with the latest version of kotlinx.coroutines
j

julioyg

04/23/2018, 2:24 PM
🙂
i

igorvd

04/23/2018, 2:27 PM
@gildor I see. Thank you very much. I'll switch for use the async api from the retrofit. I wasn't aware that all my coroutines would be blocked by doing the sync. request. But when you said, I realize that when my pool is reached, the others coroutines would need to wait for some thread to be released, right? I need some more study about blocking / non-blocking in concurrency. Do you know some good material do learn about that? 😃 Thanks in advance
g

gildor

04/23/2018, 2:33 PM
when my pool is reached, the others coroutines would need to wait for some thread to be released, right
@igorvd Correct, even non-blocking coroutines will wait. This is the reason why you shouldn’t block threads in default dispatcher, because all coroutines use it by default, and probably all non blocking ones If you want to use coroutines to wrap blocking call (similar what you could do with standard thread), just use custom dispatcher, for example for blocking DB or network requests create new dispacther using builder
newFixedThreadPoolContext
or
Executor.asCoroutineDispatcher
extension method, so it will be safe to block thread on this thread pool Default CommonPool dispatcher has only
cpuNumber - 1
threads and intended to use only for non-blocking calls
i

igorvd

04/23/2018, 2:41 PM
@gildor That's really interesting. I don't know if I miss this info on the docs, but that's the first time that I read something related to that. I'm a bit surprise that the coroutines doesn't have a dispatcher for that kinda of operations tho. But I did some search and aparently they are working on that: https://github.com/Kotlin/kotlinx.coroutines/issues/79 Thank you very much, you helped me a lot.
g

gildor

04/23/2018, 2:48 PM
Also this talk by Roman covers some basics of this topic

https://www.youtube.com/watch?v=_hfBv0a09Jc

i

igorvd

04/23/2018, 2:55 PM
@gildor oh cool. Everytime I have some doubt I usually checked the
coroutines-guide
. I haven't looked into the
informal
one. I will read and watch the talk. Thank you very much 😃
g

gildor

04/23/2018, 3:08 PM
@igorvd Main thing that you should keep in mind that coroutines is like syntactic sugar for callbacks and you can wait for some long operation using 2 approaches: lock thread or callbacks (or coroutines that have very similar approach under the hood)
👏 1
@julioyg I can check also with real Retrofit request later. Maybe you could reproduce this issue or submit PR with failed test this would help to investigate your case faster Or just provide some sample code where you reproduced this
j

julioyg

04/24/2018, 8:44 AM
thanks, so apparently it was me messing things up with the coroutine context 🤦‍♂️
5 Views