Path: csiph.com!eternal-september.org!feeder.eternal-september.org!newsfeed.kamp.net!newsfeed.kamp.net!newsfeed.freenet.ag!87.79.20.101.MISMATCH!newsreader4.netcologne.de!news.netcologne.de!feeder1.xsusenet.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!nzpost1.xs4all.net!not-for-mail
To: python-list@python.org
From: Dennis Lee Bieber <wlfraed@ix.netcom.com>
Subject: Re: asyncio, coroutines, etc. and simultaneous execution
Date: Sun, 23 Aug 2015 18:26:54 -0400
Organization: IISS Elusive Unicorn
References: <55DA3E96.6090703@earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.40.1440368823.17298.python-list@python.org>
Lines: 48
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:95601

On Sun, 23 Aug 2015 14:43:50 -0700, Charles Hixson
<charleshixsn@earthlink.net> declaimed the following:

>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.
>

	<snip>


	Is there a question somewhere in all that?

	Coroutines, by classic definition, are routines that cooperate in
switching off execution -- remember, for half the existence of electronic
digital computing, something like a multi-core computer was very rare
(vectorized super-computers, et al). 

	Where multiple processors were found, they were not general purpose...
The Sigma-6 (and most of the SDS/XDS Sigma line) had the main "computer"
and a collection of SIOP and MIOP to handle I/O transfers from between
memory and peripherals (it also had a 4-bank, 4-port interleaved memory so
the IOPs and main processor could chase each other without wait states; the
Amiga had two banks, but only CHIP RAM was 2-port, and the banks were not
interleaved, so CHIP access could block main processor)

	In common Python, the GIL affects things like number crunching (CPU
bound) algorithms, in that only the thread holding the GIL can perform
meaningful work -- so a thread in another core, not holding the GIL, is
blocked. Nothing different than a single core processor. But I/O bound
algorithms -- since the I/O library releases the GIL before blocking on
system I/O calls -- work fine with GIL and multiple cores.

	The multiprocessing module trades off the fast creation of threads
limited by the GIL for slower process startup (especially on Windows) by
giving each process its own, well, system process and Python interpreter
with its own GIL. But sharing state between these processes becomes more
complex -- you don't really have shared global objects that can be tested.

	Can't speak for asyncio -- my mind just doesn't work that way. For
asynchronous I/O, threads/Queue work for me (or VMS style non-blocking QIO
with event flags that can be tested and waited for later in the process...
ASTs if one wants something that behaves closer to an interrupt handler).
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/