Nonetheless, there were discussions about some way to force preemption at certain points, not sure whether there is a decision since, but that will be the exception, not the rule.
There is a bit of a grey area in between, where threads can be suspended outside the runtime, but not anywhere. Go had this for a while - threads could get suspended on function entry too.
If you've got a thread that's in a loop in which it doesn't allocate, doesn't call other functions, doesn't interact with the runtime in any way, maybe it's just looping over huge arrays of numbers doing calculations, then a cooperative threading runtime can't suspend it, whereas a preemptive threading runtime can.
In cooperative multithreading, a thread only enters the runtime when that is part of its normal program flow. The code it's executing does I/O, or acquires a lock, or something like that. In preemptive multithreading, some mechanism can force any thread into the thread scheduler at any time.
> Nonetheless, there were discussions about some way to force preemption at certain points, not sure whether there is a decision since, but that will be the exception, not the rule.
I'm trying to understand the difference between "forcing preemption" and requesting for the runtime to yield, the latter being an operation typical in cooperative multithreading.
That is cooperative scheduling.