I'm not sure if I already mentioned it before, any...

# coroutines

[littlelightcz]

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 👍🙂

[igorvd]

I have the exactly same extension for android, launchUI

[littlelightcz]

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.

[thevery]

I have lauchRx for migration :)

[gildor]

What is your use case for withContext(CommonPool) {}?

[elizarov]

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

[thevery]

What is your use case for withContext(CommonPool) {}?

probably offload some work off the main thread?

[gildor]

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

[thevery]

Is IO already available?

[gildor]

Nope, but you can create own one and it's the only correct way to wrap blocking calls with coroutines

[littlelightcz]

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

[littlelightcz]

Thanks @elizarov, I will go through it 🙂

[gildor]

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

[littlelightcz]

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.

[littlelightcz]

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

[thevery]

@gildor hm, what scenarios can lead to deadlock?