[pron]

Virtual threads do not do it voluntarily. They have no knowledge or control over where they might yield. Without forced preemption, I guess you can say that as long as they don't call into the JDK in any way (including e.g. throwing exceptions) or any third-party library then they shouldn't normally expect to yield, but I don't count calling any code you haven't personally written "voluntarily yielding".

We call them preemptive with or without forced preemption -- in line, I think, with the definitions on Wikipedia -- but whatever you choose call them, the concurrency programming style is the same as that with threads today or Go's goroutines, and is different from the style of C#/JS's async/await, Kotlin's coroutines, or more explicit async code, all of which result in user code relying on knowing where yield points (possibly) are (i.e. "critical section" by default). BTW, even with OS threads, when you run transaction-handling code, as opposed to long-running computation, time-sharing preemption is the exception rather than the rule.

[haxen]

I think the distinction is pretty clear: either the mechanism requires cooperation by the application thread (which typically initiates the yield at a compiled-in, predefined point), or it doesn't and the runtime environment preempts it from the outside.

Virtual threads are of the former kind. (At least as long as we don't involve the forced preemption feature).

[pron]

Virtual threads are not cooperative, and OS threads that process transactions are also normally preempted almost exclusively at syscalls initiated by the thread, but I can't stop you from calling them that. The important thing to remember is that you program them like OS threads or Go goroutines or Erlang processes ("interleaving can happen anywhere unless I forbid it") and not like async/await or Kotlin's coroutines or asynchronous code or Windows 3.0 ("interleaving can only happen at certain allowed, known points"), whatever you want to call these two styles.

[haxen]

I concur with your point about the programming model and style, but I do also maintain that "cooperative" vs. "preemptive" is not about that difference. It is a technical difference on how the system interleaves threads and whether it needs cooperation from the code running on them, and not on the programming model and critical sections.

For the distinction you have in mind, I see the terms "colored" vs. "non-colored functions" to be used the most, and they are both within the "cooperative multithreading" space.