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

This article has been on Hacker News in the past (to be fair, I think this post might be about a new venue for it).

The problem with the article is that it's superficial. At its core, it's premised on the idea that threads are inherently easier than events, because they produce straight-line code and automatically handle tracking the state needed across a transaction. If that's true, then the article says threads are just as good as events once we solve all the problems that make threads dangerous or slow.

But it's not a given that threads are easy. In particular, as anyone who has spent time doing high-performance threaded code will tell you, there's the effort you have to put in to make sure your threaded code is correct, and then the 2x more time you have to put in to make sure that it's efficient; in particular, you have to do synchronization without effectively serializing all your threads. Which is a huge pain.

I think this is gradually becoming a moot point, as modern languages --- all of which have some kind of anonymous function and some approximation of closures --- allow us to write evented code that looks and feels like straight-line code. jQ callbacks in Javascript are the most vivid illustration of this idea (I suppose the node.js people are carrying that even further; I haven't played with it).

In their evaluation it appears they are comparing their server written in C or C++ (since they call OS functions like poll) to SEDA which is written in Java. In the original SEDA paper, if I remember correctly, the authors noted SEDA wasn't as fast as one of the servers written in C that they used for comparison reasons, but the authors were just trying to demonstrate a proof of concept of the architecture.

This doesn't seem like a particularly fair comparison of architectural ideas. A better one IMHO would have been to implement their server in Java or re implement SEDA in C.

  Using the newer sys_epoll system call with Knot avoids this
  problem and achieves excellent scalability. However, we 
  have used the poll() result for comparison, since sys_epoll
  is incompatible with Haboob's socket library.

WTH? I admit I didn't read the entire thing (just skimmed), but are they actually comparing threads to poll() and declaring victory instead of epoll()? Intentionally? epoll() is radically different from poll(). Nobody uses poll() for heavy-duty event-based servers. They might as well not have said anything at all.