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

littlelightcz

08/20/2018, 5:26 PM
I'm not sure if I already mentioned it before, anyway, after a few weeks of coding TornadoFX apps I got used to create these 2 extension functions to ease up my code a bit:
launchUI {}
for
launch(JavaFx) {}
and
commonPool {}
for
withContext(CommonPool) {}
. If something similar would be considered to be added to the coroutines-javafx and base coroutines libraries, that would be a thumbs up from me 👍🙂
👍🏼 1
i

igorvd

08/20/2018, 5:49 PM
I have the exactly same extension for android,
launchUI
l

littlelightcz

08/20/2018, 6:06 PM
Great to hear that I am not alone in this 😁. Since one usually doesn't use more than 1 UI/frontend framework (especially in 1 class), it should be safe to add the same extension to the coroutines-android as well.
t

thevery

08/20/2018, 8:19 PM
I have lauchRx for migration :)
g

gildor

08/21/2018, 2:30 AM
What is your use case for
withContext(CommonPool) {}
?
e

elizarov

08/21/2018, 8:46 AM
Take a look at this crazy idea, please. It should totally remove the need for such extensions: https://github.com/Kotlin/kotlinx.coroutines/issues/428
t

thevery

08/21/2018, 9:21 AM
What is your use case for
withContext(CommonPool) {}
?
probably offload some work off the main thread?
g

gildor

08/21/2018, 9:24 AM
CommonPool should be used only for non-blocking operations, so in case of non-blocking you probably waste more time on context switch than unload work from main thread If operation is blocking than you shouldn’t use CommonPool, but something like
IO
t

thevery

08/21/2018, 10:59 AM
Is
IO
already available?
g

gildor

08/21/2018, 12:21 PM
Nope, but you can create own one and it's the only correct way to wrap blocking calls with coroutines
l

littlelightcz

08/21/2018, 4:52 PM
As Ildar already said, I want to offload the UI thread with a blocking (or "long enough") opearation and I don't mind running it on a CommonPool. I would use a dedicated IO thread pool only when I needed more threads 😁.
Thanks @elizarov, I will go through it 🙂
g

gildor

08/21/2018, 5:15 PM
This is the reason why I asked about use case for
commonPool
method, because you just shouldn't use it for any blocking operations otherwise once you will get deadlock
l

littlelightcz

08/21/2018, 6:52 PM
Hmh, actually I experienced some deadlock-like behaviour when I used coroutines before, but when I tried to reproduce it on some Foo/Bar code, I wasn't able to do that. I think that some parts of the code were using the
runBlocking {}
so I don't know if that was the cause or something else. Anyway nowadays when I launch a coroutine on the UI thread and then move blocking tasks either to CommonPool or to a different dedicated pool (using
withContext
or
async
depending on the use case), no deadlocks so far.
Maybe if the blocking operation got stuck forever, then the deadlock could appear if all the threads in the pool were blocked in this way, but it's always good practice to have reasonable timeouts on everything. So e.g. for a simple desktop app, when you do some small async stuff from time to time, I think it's ok to go with the CommonPool (at least it's very convenient 🙂 ). If I would code some web data miner, then I would go with a custom IO pool since the parallelization will be much more demanding here, etc. It depends ...
t

thevery

08/22/2018, 12:01 AM
@gildor hm, what scenarios can lead to deadlock?
4 Views