
Why Events Are A Bad Idea (for high-concurrency servers) - apu
http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/
======
tptacek
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).

~~~
mahmud
s/Popov/Popek/

~~~
tptacek
Thanks! Did what I said make sense otherwise?

~~~
mahmud
What you write always makes sense, Thomas.

------
toddh
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.

------
wmf
It would be interesting to revisit this using Go.

