Why Events Are A Bad Idea (for high-concurrency servers)

Lauer and Needham are to events and threads what Popek and Goldberg are to virtualization: a distraction. The theoretical equivalence in expressiveness between the two models has very little to do with the practical systems programming reality of implementing them.

This paper also handwaves around the difference between preemptive and cooperative threads, as if to suggest that event-scheduled I/O implementers are naturally opposed to cooperative threading. In fact, I/O loads seem to be a motivating driver for coop thread libraries. In that sense, this paper seems to be an attempt to manufacture a controversy where none exists.

Finally, the notion that cooperatively-schedule concurrent I/O is automatically synchronized only on uniprocessors is true but irrelevant. Anybody that builds a cooperative system that needs to run on multiple processors knows they need to synchronize. The point is that coop systems are explicitly synchronized and have stated that is unshared by default, which eliminates large classes of errors (not just straightforward stuff, but also thread serialization and performance issues).

Latency is impossible to guarantee with both threads and events, so neither is very good from that perspective. They don't talk about dead lock either or thread pool exhaustion. Meaningfully assigning thread priorities is nearly impossible as well. Neither is a good abstraction.

It would be interesting to revisit this using Go.