Terry Reedy <tjre...@udel.edu>: > I do not understand this. asyncio should switch between tasks faster > than the OS switches between threads, thus reducing waiting time.
I don't know if thread switching is slower than task switching. However, there are two main reasons to prefer asyncio over threads: * Scalability. Asyncio can easily manage, say, a million contexts. Most operating systems will have a hard time managing more than about a thousand threads. Such scalability needs may arise in very busy network servers with tens of thousands of simultaneous connections or computer games that simulate thousands of "monsters." * Conceptual simplicity. Toy servers are far easier to implement using threads. However, before long, the seeming simplicity turns out to be a complication: - Thread programming assumes each thread is waiting for precisely one external stimulus in any given state -- in practice, each state must be prepared to handle quite a few possible stimuli. - Thread-safe programming is easy to explain but devilishly difficult to get right. Asyncio makes the prototype somewhat cumbersome to write. However, once it is done, adding features, stimuli and states is a routine matter. Threads have one major advantage: they can naturally take advantage of multiple CPU cores. Generally, I would stay away from threads and use multiple processes instead. However, threads may sometimes be the optimal solution. The key is to keep the number of threads small (maybe twice the number of CPUs). Marko -- https://mail.python.org/mailman/listinfo/python-list