
Unyielding (On Threads) - rdegges
https://glyph.twistedmatrix.com/2014/02/unyielding.html
======
PaulHoule
Yes threads are bad but going to asynchronous programming can be like going
from the frying pan to the fire -- one of those things that generations of
programmers seem to learn time and time again.

In the 1970s there were two control programs developed for the space shuttle,
one asynchronous by IBM and a synchronous one by Rockwell that was much
simpler. They tested them side by side and found a timing mismatch and their
first instinct was that Rockwell was wrong but really IBM was wrong.

Back in 2000 I was involved with a site that had a 100MB or so download
associated and the boss didn't like the high process count it took to serve
with Apache so we tried a number of the open-source "single process" web
servers that used asynchronous I/O and we found that all of them (at the time)
were associated with failing downloads and corrupted data, so we went back to
Apache.

In the 2006-2010 time frame I was involved in a number of front-end client
projects using tools such as GWT and Silverlight where the other people
involved were flummoxed with the complexity of async comm and I was able to
get things working by imposing a definite discipline on how information flowed
in the application, that is, having visual objects in the UI register
themselves against a communications framework that would notify them of
changes.

Ultimately that is what you need to do to succeed with threads: I've had very
good luck with Executors in Java, especially the LMAX Disruptor. Not every
problem fits into the Executor framework, but for the ones that do, I get
consistently good results as compared to various "fork-join", "actor" and
other snake oil frameworks.

