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).
I think what he's really getting at is that user-space threading is effectively underrated. There are models for cooperative threading using coroutines, such as Ruby's Fiber that are underutilized. One just has to be careful to make sure all blocking operations will suspend and swap coroutines.
"Closures" and user-space threads are two different approaches to the same end-state, which is code that is scheduled on I/O events instead of timeslices, and that implicitly manages all the state involved in the request.
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.
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).