asyncio, coroutines, etc. and simultaneous execution

[Akira Li]

Charles Hixson <charleshixsn at earthlink.net> writes:

> If I understand correctly asyncio, coroutines, etc. (and, of course,
> Threads) are not simultaneously executed, and that if one wants that
> one must still use multiprocessing.  But I'm not sure.  The note is
> still there at the start of threading, so I'm pretty sure about that
> one.

Due to GIL (used by CPython, Pypy, not used by Jython, IronPython,
pypy-stm) only one thread executes Python bytecode at a time. GIL can be
released on I/O or in a C extension such as numpy, lxml, regex. It is
true for any Python module or concept you use.

Unrelated: use concurrent and parallel execution instead of
"simultaneously executed."

Parallelism might make a program faster (it implies that hardware
supports it).

Concurrency is a way to structure the code. The same concurrent program
can run in parallel and without parallelism.

Recommended: "Concurrency is not Parallelism
(it's better!)" talk by Rob Pike's talk
http://stackoverflow.com/questions/1050222/concurrency-vs-parallelism-what-is-the-difference


> The requirement that coroutines always be awaited seems to confirm
> this, but doesn't really say so explicitly. And the concurrent.futures
> can clearly be either, depending on your choices, but the chart in
> 18.5.3.1.3 Example: Chain coroutines is of a kind that I am more
> familiar with in the context of multiprocessing. (E.g., the only gap
> in the chart, which extends across all headings is when a result is
> being waited for during a sleep.)  For threaded execution I would
> expect there to be a gap whenever processing is shifted from one
> column to another.
>
> If someone has authority to edit the documentation a comment like:

Anybody can suggest a patch
https://docs.python.org/devguide/docquality.html

> If you want your application to make better use of the computational
> resources of multi-core machines, you are advised to use
> multiprocessing
> <https://docs.python.org/3.5/library/multiprocessing.html#module-multiprocessing>
> or concurrent.futures.ProcessPoolExecutor
> <https://docs.python.org/3.5/library/concurrent.futures.html#concurrent.futures.ProcessPoolExecutor>. However,
> threading is still an appropriate model if you want to run multiple
> I/O-bound tasks simultaneously.
>
> (to quote from the threading documentation) would be helpful at or
> very near the top of each of the appropriate modules.  It would also
> be useful if the modules that were definitely intended to result in
> simultaneous execution, when feasible, were so marked quite near the
> top.

It is not necessary that multiprocessing will make your code faster on a
multi-core machine. It may make it slower depending on the task.

Performance optimization is a vast topic. Short remarks such as you've
suggested are likely misleading.

> OTOH, I may be mistaken about coroutines.  I haven't been able to tell.

Many cooperative multitasking implementations use a *single*
thread. There is a way to offload blocking code e.g.,
loop.run_in_executor() in asyncio.