3 ms·
Unyielding (On Threads)
- PaulHoule 10y agoYes 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.