<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 25, 2017 at 10:33 PM, Guido van Rossum <span dir="ltr"><<a href="mailto:gvanrossum@gmail.com" target="_blank">gvanrossum@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jun 25, 2017 at 3:38 PM, Yarko Tymciurak <span dir="ltr"><<a href="mailto:yarkot1@gmail.com" target="_blank">yarkot1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote">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.<br clear="all"></div></div></blockquote><div><br></div><div>Before anyone takes this paragraph too seriously, there seem to be a bunch of misunderstandings underlying this paragraph.<br></div></div></div></div></blockquote><div><br></div><div>yes - thanks for the clarifications...  I'm speaking from the perspective of an ECE, and thinking in the small-scale (embedded) of things like when in general is cooperative multitasking (very light-weight) more performant than pre-emptive... so from that space: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>- *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`.)<br><br>- 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.)<br><br>- Using async tasks don't make globals more risky than regular code (in fact they are safer here than in traditional multi-threaded code).<br><br></div><div>- What on earth is "read/write" control from memory space w/in the process?<span class="HOEnZb"><font color="#888888"><br></font></span></div></div><span class="HOEnZb"><font color="#888888"><br>-- <br><div class="m_-7806132034769517223gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</font></span></div></div>
</blockquote></div><br></div></div>