The problem with the event-loop based model (or cooperative multitasking, in Windows 3.1 parlance) is that you lose control over latency. You see, just like timers, files, and the network, the CPU is a resource too. And it needs to be managed. One event using a too large chunk of CPU time, and the latency in the handling of the other events goes up.
Only in a world where code gives up control perfectly. But in practice, this is very difficult to achieve. The language basically provides no tools. And using concepts like coroutines/generators is just messy in practice. So while you can do it in theory, in practice it can quickly become a nightmare of chasing "uncooperative" parts of code, with a slow user-experience as the end-result.
It is also "bad software-engineering", as you are now forced to think about slicing up your code, which, in an already complicated application, can lead to bad code.
Comments
The problem with the event-loop based model (or cooperative multitasking, in Windows 3.1 parlance) is that you lose control over latency. You see, just like timers, files, and the network, the CPU is a resource too. And it needs to be managed. One event using a too large chunk of CPU time, and the latency in the handling of the other events goes up.
Wouldn't a cooperative event loop handle that? You divide CPU time between event handlers, so one event handler can't block others.
Only in a world where code gives up control perfectly. But in practice, this is very difficult to achieve. The language basically provides no tools. And using concepts like coroutines/generators is just messy in practice. So while you can do it in theory, in practice it can quickly become a nightmare of chasing "uncooperative" parts of code, with a slow user-experience as the end-result.
It is also "bad software-engineering", as you are now forced to think about slicing up your code, which, in an already complicated application, can lead to bad code.
preemptive green thread solve that.