What would your suggestion be on firing a lot of f...
# coroutines
b
What would your suggestion be on firing a lot of fire-and-forget http-request with coroutines? 1. GlobalScope? 2. An explicit scope with supervisor job? 3. Something else? I’m leaning towards the second, but I don’t really know if I’m missing something here.
p
Everybody seems to suggest to never use the GlobalScope, but imo no2 does not bring any benefit over no1, so I'd go with GlobalScope
t
Isn’t GlobalScope going to stop the request when application is closed?
p
Everything is stopped when your application stops
t
Thought only GlobalScope is daemon
I’m still learning so I’m not sure how things really work
b
I think the general problem is that all examples shows more specific examples and all say “Don’t use GlobalScope”. My reason for considering not using it is cause 1. I don’t like the naming.. so purely cosmetical. Secondly I figured I could do a error-handler that is specific for the statistics-calls if having a more specific scope.
I could probably just have a handler val passed on when launching from GlobalScope as well to get the same result.
I know I said fire and forget.. but I want to log the errors, even if I don’t act on them.
n
Then I would say create your own scope that uses the main dispatcher and hook in your error handling there. You can "fire and forget" by using
async
and having a
CoroutineExceptionHandler
attached to your scope.
👆 1
b
Now I'm confused.. as: "`CoroutinesExceptionHandler` is invoked only on exceptions which are not expected to be handled by the user, so registering it in
async
builder and the like of it has no effect." But you're suggesting the opposite? I need to try this out.
m
b
@MiSikora thanks, but how does this help my case anyhow?
m
Oh, sorry. I thought you are alredy in some scope and want to fire and forget from it.
👍 1
j
does kotlin have an EPOLL or NIO aync http[s]client yet? figure the number of requests is less important than gc optimal to 2GB per core in flight
g
Yes, Ktor client has Netty and CIO drivers which are non blocking
If you just don't like naming, introduce own global scope, not sure what is consideration between 1 and 2, they are essentially the same thing
b
I wanted hear what differences there actually was between 1 and 2.
g
Depends on how option 2 implemented, but if it does exactly the same what GlobalScope does (with Supervisor or not): returns empty context without job, it will be the same; https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-core/common/src/CoroutineScope.kt#L132