On Sun, Jun 25, 2017 at 3:38 PM, Yarko Tymciurak <yarkot1@gmail.com> wrote:
To be a well-behaved (capable of effective cooperation) task in such a system, you should guard against getting embroiled in potentially blocking I/O tasks whose latency you are not able to control (within facilities available in a cooperative multitasking context).  The raises a couple of questions: to be well-behaved, simple control flow is desireable (i.e. not nested layers of yields, except perhaps for a pipeline case); and "read/write" control from memory space w/in the process (since external I/O is generally not for async) begs the question: what for?  Eliminate globals, encapsulate and limit access as needed through usual programming methods.

Before anyone takes this paragraph too seriously, there seem to be a bunch of misunderstandings underlying this paragraph.

- *All* blocking I/O is wrong in an async task, regardless of whether you can control its latency. (The only safe way to do I/O is using a primitive that works with `await`.)

- There's nothing wrong with `yield` itself. (You shouldn't do I/O in a generator used in an async task -- but that's just due to the general ban on I/O.)

- Using async tasks don't make globals more risky than regular code (in fact they are safer here than in traditional multi-threaded code).

- What on earth is "read/write" control from memory space w/in the process?

--
--Guido van Rossum (python.org/~guido)