"processes voluntarily yield control periodically or when idle or logically blocked in order to enable multiple applications to be run concurrently."
This tells me virtual threads (without forced preemption) are cooperative.
This tells me virtual threads (without forced preemption) are cooperative.
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.
Virtual threads are of the former kind. (At least as long as we don't involve the forced preemption feature).
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.