
Thousands of Threads and Blocking I/O [pdf] - tianyicui
http://www.mailinator.com/tymaPaulMultithreaded.pdf
======
jerf
It's really a pity the "synchronous" terminology took off, as if the layout of
the text of the source code has any particular relationship to the efficiency
of the underlying scheduling and multitasking primitives. In the end what
matters for the code complexity is how the threads can interact with each
other (shared memory, messages, etc) and how thoroughly those things are
enforced, and the performance is about the efficiency and power of the
underlying scheduler and processing. How your code looks in the editor doesn't
enter into it.

Things with bad thread interaction stories and inefficient or ineffective
schedulers aren't going to be the Next Big Language, no matter how cool they
sound today.

The results in this article are a lot less weird or counterintuitive if you
understand that.

------
davidhollander
Eh, I would just limit the front process to coroutines accepting incoming
connections and accepting complete responses from remote procedure calls and
use neither threads nor polling. Launch a lot of worker processes to divide
and conquer all the actual work, restart some on the other end of a TCP/IP
connection if scaling is necessary. But that's my preference.

------
Groxx
Previously: <http://news.ycombinator.com/item?id=1551776>

An interesting set of slides. Also interesting is the URL. Is this seriously
the only copy of this slide deck?

~~~
bretthoerner
The URL seems weird at first, but Paul created mailinator, it's as permanent a
URL to him as random-joes-domain.com is for Random Joe.

[http://paultyma.blogspot.com/2008/03/writing-java-
multithrea...](http://paultyma.blogspot.com/2008/03/writing-java-
multithreaded-servers.html)

------
otterley
The performance analysis is pretty bad. Comparing synchronous I/O performance
against asynchronous I/O based solely in terms of bits per second transferred
only tells a small part of the story. It doesn't show how well the server
scales as more and more connections are added, which absolutely essential
information. It would have been far better if the author had plotted the
connection rate and response time against the transfer size per connection.

