asyncio, coroutines, etc. and simultaneous execution
Sven R. Kunze
srkunze at mail.de
Mon Aug 24 17:35:04 EDT 2015
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>
More information about the Python-list
mailing list