"Frank Millman" <fr...@chagford.com>: > I am finding difficulty in understanding the benefit of going async in > my case. If most requests require a blocking handler, it seems that I > might as well stick with each request being handled by a thread, > independent of all other threads.
When the underlying facilities only provide blocking access, you are forced to use threads (or processes). One area where asynchronous programming was always the method of choice is graphical user interfaces. The GUI of an application must always be responsive to the user and must be prepared to handle any of numerous stimuli. Network protocol layers are also usually implemented asynchronously. The protocol standards read like asynchronous programs so the translation into executable programs is most natural in the asynchronous style. Here, too, the networking entities must be ready for different stimuli in any state, so threads are usually not a good fit. Kernel programming makes use of threads and processes. However, the asynchronous style is there in a big way in the form of interrupt handlers, hooks and system calls. Really, the threading model is only good for a relatively small subset of programming objectives, and over the lifetime of the solution, you will often come to realize threading wasn't that good a fit after all. Namely, in any given state, you will have to be prepared to handle more than one stimulus. Also, over time you will learn to dread the race conditions that are endemic in thread programming. Those are the kinds of problems that make you check out the current job postings. Only there's no escape: in your next job, they are going to make you find and fix the race conditions in your predecessor's code. Marko -- https://mail.python.org/mailman/listinfo/python-list
