[Async-sig] "read-write" synchronization

[Yarko Tymciurak]

On Sun, Jun 25, 2017 at 10:33 PM, Guido van Rossum <gvanrossum at gmail.com>
wrote:

> On Sun, Jun 25, 2017 at 3:38 PM, Yarko Tymciurak <yarkot1 at 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.
>

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:

>
> - *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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20170625/a1442a84/attachment-0001.html>