<@U0BRK9HC5> I've just come up with your lib and w...

# coroutines

[julioyg]

@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?)

[gildor]

@julioyg Hi Julio, it is. Request will be cancelled after coroutine cancellation

[gildor]

Check this function https://github.com/gildor/kotlin-coroutines-retrofit/blob/master/src/main/kotlin/ru/gildor/coroutines/retrofit/CallAwait.kt#L102

[julioyg]

thanks, I was doing that and it's not working, then must be me doing something wrong

[igorvd]

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:

async {  call.execute() }.await()

[julioyg]

@gildor

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?

[gildor]

@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

[gildor]

@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

[gildor]

@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

[gildor]

@julioyg let me check with the latest version of kotlinx.coroutines

[julioyg]

🙂

[igorvd]

@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

[gildor]

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

[igorvd]

@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.

[gildor]

@igorvd
Official coroutine guides cover some topics about blocking and non blocking API
https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md
https://github.com/Kotlin/kotlin-coroutines/blob/master/kotlin-coroutines-informal.md

[gildor]

Also this talk by Roman covers some basics of this topic

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

[igorvd]

@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 😃

[gildor]

@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)

[gildor]

@julioyg My “synthetic” (with mocked request implementation) cancellation tests are passed even with kotlinx.coroutines 0.22.5
This is how I test it:
https://github.com/gildor/kotlin-coroutines-retrofit/blob/v0.9.0/src/test/kotlin/ru/gildor/coroutines/retrofit/CallAwaitTest.kt#L265-L273
https://github.com/gildor/kotlin-coroutines-retrofit/blob/v0.9.0/src/test/kotlin/ru/gildor/coroutines/retrofit/CallAwaitTest.kt#L50-L63

[gildor]

@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

[julioyg]

thanks, so apparently it was me messing things up with the coroutine context 🤦‍♂️