Rule of thumb: coroutines are for asynchronous tasks that wait for something most of the time. Threads are for CPU-intensive tasks.

elizarov: I have a use case where I have a rendering pipeline of sorts. I have a repeating cycle of doing some CPU intensive tasks, then writing the results to disk. This it repeated for an arbitrary number of frames. The results are appended to the same file, and the results of a frame are dependent on the previous frame, so I have to do it in order, but I may have several "renders" going on at the same time. Would coroutines provide an advantage over threads in this case?

It is hard to tell. Maybe, maybe not. It really depends on how your code is structure and whether coroutines can let you improve the structure and readability of your code.

Fair enough. It's still in the very early stages, so the design could change. I'll ask again when I have a more concrete design.

Sorry for picking up this thread so late, but why would coroutines with CommonPool not as good as directly using threads?

They will just as good. No worse, but no better, either, unless your tasks wait for something, if which case you get immense value out of coroutines (threads are not blocked, but the coding style is still natural)

Just as I thought. So is there really any scenario where threads are clearly better than coroutines with a similarly sized thread pool? the only thing I can think of is the coroutines scheduler overhead. But even that seems not real: either all the threads are unsynchronized in which case the coroutines are as well or there is some sync and then most likely the coroutines abstractions are better then whatever I would hand-craft.

There is a bit of extra overhead + an extra depenency. So, if you’re not reaping any coroutines benefits, then why…

why: because the coroutines abstractions are so much nicer than directly programming with threads. Perhaps I will change my minds once you finished kotlinx.threads 🙂

Yes. You can say that.