

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

======
tptacek
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).

~~~
rbranson
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.

~~~
tptacek
"Userspace threading vs. event programming" is a fake controversy. Event
advocates tend to be userspace/nonpreemptive thread advocates.

~~~
rbranson
Not always. Node.js is very opinionated on advocating a closure-based model
versus user-space threading.

~~~
tptacek
"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.

~~~
rbranson
I can agree with you on this abstraction :)

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

------
itistoday

      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.

