Asynchronous programming

[Chris Angelico]

On Thu, Aug 11, 2016 at 3:06 PM, Paul Rubin <no.email at nospam.invalid> wrote:
> The basic reason to do it is it lets you serve a lot of concurrent i/o
> channels (network connections, say) without using threads.  If you want
> to read a packet, you launch a non-blocking read that returns
> immediately, and then transfer control (often through some
> behind-the-scenes magic) to an event loop that dispatches back to you
> after your read request completes, through either a callback or a
> coroutine jump depending on which framework you're using.  In Python
> that gets you much higher performance than threads, plus you avoid the
> usual bunch of hazards that parents used to scare their kids with about
> multi-threaded programming.
>

Hmm. I'm not sure about that last bit. In order to properly support
asynchronous I/O and the concurrency and reentrancy that that implies,
you basically need all the same disciplines that you would for
threaded programming - no shared mutable state, keep your locals
local, etc. The only difference is that context switches are coarser
than they are in threading (and remember, CPython already refuses to
switch threads in the middle of one bytecode operation, so most of the
worst horrors can't happen even there). But maybe I'm too comfortable
with threads. It's entirely possible; my first taste of reentrancy was
interrupt handling in real mode 80x86 assembly language, and in
comparison to that, threads are pretty benign!

ChrisA