Even with Python (CGI backed by Apache), you can scale with threads. The issue of scaling with threads vs. events is a pretty hot debate, and I think the author sets up this kind of criticism by addressing it poorly. Personally, I fall into the event-driven camp, because it involves the operating system as little as possible (only file descriptors). The C10K link has a great overview of the threaded approach (http://www.kegel.com/c10k.html#threaded). Read through the rest of the page for a discussion on the pros/cons of other approaches.
Another issue with evented frameworks in python is that you have to ensure nothing is blocking anywhere in your code, which becomes harder the more complex your application becomes. People will often mention IO, database, etc... forgetting that it is also an issue if your request handler takes CPU for N ms (e.g. encoding a relatively large payload in json, etc...). everything needs to be written with async in mind.
Languages/frameworks where async IO is an implementation detail (like some web frameworks in haskell) don't have this issue.
I don't think of this as a problem. Tornado is just a small and lightweight non-blocking HTTP server with a couple of convenient libraries. There are some pretty awesome, elegant solutions to the problem you point out, and I like to think of these as extensions to the small Tornado framework.
For heavy computational tasks that aren't time-critical, you could have an accessory worker thread that chugs queued computations (yay first-class functions) in computational downtime.
Tornado devs recommend using blocking mysql drivers and disk I/O. These operations have relatively low and predictable latencies. You can run more Tornado processes than the number of cores is if CPU is underutilized.
Well, actually, it involves the operating system rather heavily. select, epoll, kqueue, etc., etc., are not user-space things, after all, and if the OS implementation is bad, you are going to run into trouble.
Yes, they of course involve the OS, but are much lighter than overhead from spawning a thread. Furthermore, what's the point in considering bad OS implementations? Linux is free and does a good enough job, so that should be the baseline for considering performance.
I'm not entirely in either camp, I don't think event-driven programming is worse or even bad. I'm just sick of false arguments in either direction! (Especially as a Java developer who tried to learn nio only to find out that using lots of threads was fine all along... not a pleasant journey!)
