This also adds CancelledError exception and makes TimeoutError be a
subclass of it. As well as adds default exception handler for it in
the eventloop (which just skips re-adding this coro to the scheduling
queue, as expected).
Coros which removed from normal scheduling queue (and possibly put into
another queue, like I/O queue here) are marked with .pend_throw(False).
If wait_for() cancels such a coro, it is explicitly scheduled for execution,
so they actually could process pending exception (coro's exception handler
should take care of removing it from another queue and related clean up).
Currently executed task is a top-level coroutine scheduled in the event
loop (note that sub-coroutines aren't scheduled in the event loop and
are executed implicitly by yield from/await, driven by top-level coro).
yield False won't reschedule current coroutine to be run again. This is
useful when coro is put on some waiting queue (and is similar to what
yield IORead/yield IOWrite do).
If there is a coroutine to run immediately (with wait delay <= 0),
uasyncio.core never called .wait() method, which is required to
process I/O events (and schedule coroutines waiting for them). So
now, call .wait(0) even if there's a coroutine to run immediately.
uasyncio uses different timebase than CPython's asyncio, so absolute
time scheduling compatible with it is impossible. Instead, there's
call_at_() which schedules using modular millisecond time.
wait() may finish prematurely due to I/O completion, and schedule new,
earlier than before tasks to run. So, after call to wait(), we need to
check current time and time of head task, and continue to wait if needed.
Recently introduced provisional utimeq.peektime() is used to optimize
querying time of a head task.
Allows zero-allocation scheduling of tasks. As long as tasks don't use
await/yield from with coroutines, and don't allocate memory themselves,
there will be no allocation and GC.
The old name is deprecated since CPyton 3.4.4. That's great relief, because
CPython has special parser hacks to support both 3.5-style "async" keyword,
and still allow it be used as an identifier in other contexts. MicroPython
lacks such hacks, so "async" is SyntaxError as a function name with the latest
versions which implement async keyword.
Paul Sokolovsky