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

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).


Reply via email to