> with results ranging from "unusable" to "usable but probably not something you should put into production" [1]. > So for these languages, "spawning lots of t

> with results ranging from "unusable" to "usable but probably not something you should put into production" [1]. > So for these languages, "spawning lots of threads and using the OS scheduler" is simply not an option. Threaded Python applications are extremely common and are in widespread production use. The popular mod_wsgi Apache plugin is typically run in "daemon" mode where the Python code is run in a threaded server. The issue where "spawning lots of threads" is not an option is when you are trying to parallelize IO in the range of many hundreds/thousands of concurrent connections within a single process. But that is not the general use case, because that process can only use one CPU core at a time which even for an IO-heavy process still presents a limiting factor. The typical "I want to run a web server" has fairly CPU-busy Python processes where a process typically handles a few dozen simultaneous requests, and for CPU parallelism you use multiple processes. Python has more CPU-busyness than people expect sometimes because it is after all an interpreted scripting language.