

Why Events Are A Bad Idea (for high-concurrency servers) - n_are_q
http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/

======
kls
_For instance, many event systems “call” a method in another module by sending
an event and expect a “return” from that method via a similar event mechanism.
In order to understand the application, the programmer must mentally match
these call/return pairs, even when they are in different parts of the code._

I somewhat disagree with this assessment. Just as there are different
threading models, there are different event models. What the article describes
is a pub/sub model of which I am not a big fan. I prefer an event observer
model where an event as a very defined namespace and method signature or
interface. Observers must conform to that interface to observe the event,
therefore to find code relate to that event one only need look up what
implements the events interface. I find that the way event based systems deal
with control flow reduces a great deal of control flow programming which is
where a lot of spaghetti gets implemented. Choosing the proper event model is
just as important as choosing the correct threading model.

------
lcargill99
Event driven is very likely more reliable. It's also less intuitive, up to a
point. But event driven systems can be very nearly deterministic.

It's nice to see preemptive multitasking given yet another black eye. If you
really are interested in determinism and throughput, event driven _probably_
yields the best results. But much of that is design discipline - in my
opinion, for high reliability, use cases by message sequence chart is
certainly up there as a paradigm. It's much easier to audit for "correctness"
( and so long as you completely enumerate all preconditions, it gets
asymptotically close to correct behavior ). One could do worse than a Rhapsody
approach to design, even if you don't generate code from it.

 _This being said_ , I can see how threading might be a better choice for rich
multiprocessor systems, if one can design a cache regime to take advantage of
the location of state.

