The JVM supports the call Thread.interrupt() this will break a thread out of several other operations such as wait(). In order to send the interrupt() from another thread you need to get access to the thread in question. This might be easier to do if you are explicitly starting the threads yourself.

Note: The argument here is that you need to know the identity of the Thread, it would still be possible to do this with pinned coroutines, but I am not sure extra work to co-ordinate the setup is worth it.

Outside of this very specific use case...

You can trivially pin a coroutine to a thread (just avoid using suspend functions). So once the setup is complete I think that you are in an identical situation (one thread running one block of code) regardless if you started it with a coroutine or a Thread, so for practical purposes I think we can say that, after initial setup:

• There are situations where (unpinned) coroutines are better than threads.
• There are no situations where Threads are better than (pinned) coroutines.

Coroutines try to hide the existence of real threads from your programming model. If required you can pin a coroutine to a thread (by not using suspend functions) so the functionality is largely identical (between manual threads and pinned coroutines).

However the very abstraction that coroutines provide may be a problem, if:

• You need the identity of the thread.
• You need fine control of the lifetime of the thread / total number of threads.

The JVM supports the call Thread.interrupt() this will break a thread out of several other operations such as wait(). In order to send the interrupt() from another thread you need to get access to the thread in question. This might be easier to do if you are explicitly starting the threads yourself (i.e you know the identity).

I can't come up with a concrete example of when you would need to explicitly start and stop threads - in that having a pool of threads with some being idle doesn't seem to be particularly problematic, but if such a case exists then again you may need to start threads manually and Thread.join() them at the end.

I can come up with two VERY contrived examples where Threads provide a minor advantage over coroutines for example, I think that when you use Kotlin coroutines the main thread is always blocked (unused) so you end up with one extra thread over simply being able to start 1 less thread manually. Additionally I would have to benchmark the one-time setup cost of coroutines, it's probably slightly more than just setting up raw threads, however it is probably minuscule - whichever is worse.

You can trivially pin a coroutine to a thread (just avoid using suspend functions). So once the setup is complete I think that you are in an identical situation (one thread running one block of code) regardless if you started it with a coroutine or a Thread, so for practical purposes I think we can say that, after initial setup:

• There are situations where (unpinned) coroutines are better than threads.
• There are no situations where Threads are better than (pinned) coroutines.

The JVM supports the call Thread.interrupt() this will break a thread out of several other operations such as wait(). In order to send the interrupt() from another thread you need to get access to the thread in question. This might be easier to do if you are explicitly starting the threads yourself.

Note: The argument here is that you need to know the identity of the Thread, it would still be possible to do this with pinned coroutines, but I am not sure extra work to co-ordinate the setup is worth it.

Outside of this very specific use case...

You can trivially pin a coroutine to a thread (just avoid using suspend functions). So once the setup is complete I think that you are in an identical situation (one thread running one block of code) regardless if you started it with a coroutine or a Thread, so for practical purposes I think we can say that, after initial setup:

• There are situations where (unpinned) coroutines are better than threads.
• There are no situations where Threads are better than (pinned) coroutines.