asyncio, coroutines, etc. and simultaneous execution

[Sven R. Kunze]

On 23.08.2015 23:43, Charles Hixson wrote:
> 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.
>
> 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:
>
> 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.
>
> OTOH, I may be mistaken about coroutines.  I haven't been able to tell.
>
> P.S.:  I do note that the threading comment was a "*CPython 
> implementation detail:"*, and not a part of the Python 
> specifications.  But CPython is, I believe, a sufficiently dominant 
> implementation that such details are quite important.
>
>

We already have a discussion on python-ideas where we collected many 
many aspects on this particular subject.

The results so far: 
https://mail.python.org/pipermail/python-ideas/2015-July/034813.html

I know the table is a bit screwed but you will be able to handle that.

Do you have anything you want to add to it?

Cheers,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20150824/ec342b79/attachment.html>