
Why Events Are a Bad Idea (for high-concurrency servers) (2003) [pdf] - relyio
https://people.eecs.berkeley.edu/~brewer/papers/threads-hotos-2003.pdf
======
mjevans
Modern processors are much faster than the outlying memory and persistent
storage devices. They and compilers in combination are relatively good at
optimizing for predictable patterns of using sequential blocks of the outlying
memory. Context switches between tasks are expensive, because the state of the
processor must be (at least partially) serialized and stored as well as the
loss of the implicit context of the caches.

Thus it makes /far/ more sense to have a number of threads (dependent on the
hardware capacity and how readily the problem can be divided to independent or
very loosely coupled tasks) which poll message queues than it does to have a
completely independent thread for every event.

Languages based around message passing are thus the obvious choice for this
type of programming.

~~~
eggie5
What modern server is this describing? "a number of threads ... which poll
message queues..."

and what is this describing? "...a completely independent thread for every
event."

"Languages based around message passing are thus the obvious choice for this
type of programming." Ruby? Obj-c?

~~~
mjevans
The two languages that come to /my/ mind are Erlang and Go.

Other programmers might have different choices. There's no reason you couldn't
use a language that has threads to implement the N threads with event queues
model, or something similar for that language if it has shared memory. If the
language of choice lacks it you might be able to use a similar multi-process
(externally) load-balanced model.

------
EGreg
A few years later, Igor Sysoev will make NGinX which will blow Apache away in
speed, and Apache 2 will adopt the paradigm.

~~~
SwellJoe
There were _many_ fast(er than Apache) web servers before nginx, many using
various concurrency models, including the one used by nginx.

------
CodeWriter23
Threads vs. events is a false dichotomy to me. Currently writing an event-
driven finite state machine dispatcher that fires up threaded processes to
perform long-running tasks that do not modify state. The FSM brings order and
structure to chaotic event interactions, while threading enables full
utilization of CPU cores. All the better to drain your battery, lol. Seriously
though, I made this choice to balance reliability with responsivenes.

Choose the right tool for the job.

~~~
bullen
I agree that they are not contradictory but rather complementary:
[https://github.com/tinspin/rupy](https://github.com/tinspin/rupy)

My web server uses multi-threaded events.

So both!

------
metalliqaz
Modern version of "considered harmful."

------
geezerjay
here's a link to a related discussion on HN entitled Why Threads are a Bad
Idea (for most purposes) (1995)"

[https://news.ycombinator.com/item?id=14547063](https://news.ycombinator.com/item?id=14547063)

