MicroPython Forum (Archive)

This thread wasn't updated for awhile, but uasyncio discussion was happening in other forum threads, e.g. viewtopic.php?f=16&t=2966

It's hard to summarize what happened to uasyncio over these 2 years, but here's a try:

1. Optimizations and more optimizations.
2. uasyncio.core scheduling loop can run without memory allocation, i.e. suitable for near-realtime usage.
3. Switched to utime.ticks_ms() as the timing source.
4. Fixing issues (mis-scheduling case, etc.)
5. With all the refactorings and optimizations above, uasyncio can run on bare-metal ports (see the thread linked above).

What are next plans for uasyncio? Here're some ideas:

1. At the high-level, long-term plans, uasyncio diverges more and more form CPython's asyncio. At the same time, more CPython-level libraries appear which criticize asyncio's way, and offer alternatives approaches/paradigms. One such library is Curio, and the recent discovery (for me) is Trio. I was astonished that some of the criticism from author of Trio shared (https://vorpus.org/blog/some-thoughts-o ... ait-world/) is almost word-for-word follow what I said back in 2014/2015 (see e.g. beginning of this thread). The takeaway: maybe following asyncio API isn't that great a feature, and waving bye-bye to it would be a better choice.

2. At the mid-level, initial usecase for uasyncio was writing webapps on the Unix port. The work is underway to both optimize it for low-memory baremetal ports, and add functionality required for general-purpose cooperative scheduling library. Working in this direction requires changes to MicroPython core, and recently, it seems that these efforts came to a grind and/or deadlock.

3. A specific feature which is being implemented is support for timeouts. This feature is of course very important for developing real-world, robust code.

Support for timeouts (while maintaining minimality and optimality) requires adding extensions to MicroPython beyond what's available in CPython. A particular patch required for efficient timeout support is https://github.com/micropython/micropython/pull/3380. This patch was submitted 1.5 months ago and didn't receive any comments from MicroPython BDFL. While, some other my patches adding MicroPython-specific optimal functionality, received resistance.


I just released uasyncio.core 1.6, which implements initial version of wait_for() function for timeouts, and requires the patch above. However, if you don't use that function, it will still run on the mainline MicroPython. However, to implement timeouts on uasyncio package level (i.e. I/O scheduling), the patch above will be needed even for existing operations.

I don't know where this situation will lead. The uasyncio (and micropython-lib) development will definitely continue, but perhaps in a fork.

Great work! Good to see PR221 merged

the way sleep() is implemented, it won't be easy to make it cancellable

Am I right, if we have scheduled coroutine with `await asyncio.sleep(10 ** 10)` we can't cancel it until 10 ** 10 seconds gone? If so, then this definitely should be fixed.

pohmelie wrote: ↑

Sun Dec 10, 2017 12:57 pm

Am I right, if we have scheduled coroutine with `await asyncio.sleep(10 ** 10)` we can't cancel it until 10 ** 10 seconds gone? If so, then this definitely should be fixed.

Not quite. If you scheduled a coroutine with `await asyncio.sleep(10 ** 10)`, then you won't be able to cancel it. Everyone else, simply wouldn't put a coro on such sleep if they wanted to be able to cancel it .

On the other hand, I have a lot of ideas and some prototypes on how to make tasks truly deletable from the queue, how to save some memory, while making some schedulings non-deterministic, but still fair, etc. They may be able to address that sleep issue too.

Ah, got it. uasyncio have no handles for task cancellation.

pfalcon wrote: ↑

Sun Dec 10, 2017 1:55 pm

Everyone else, simply wouldn't put a coro on such sleep if they wanted to be able to cancel it .

What if I have "checker" coroutine, which make some request via network and wait 1 minute with sleep for next? If I hit ctrl-c, then I need to wait for 60 seconds until I can make cleanup/logging in finally part?

pohmelie wrote: ↑

Sun Dec 10, 2017 3:02 pm

Ah, got it. uasyncio have no handles for task cancellation.

Task cancellation can be achieved with the latest build - an example of how it can be done may be found here https://github.com/peterhinch/micropyth ... ncellation. But you are correct in that a sleep can't be interrupted: the task will only be cancelled when the sleep terminates and the task is scheduled. The obvious fix is to break up a long sleep into shorter ones. If you want a long delay with a maximum cancellation latency of (say) 3 seconds issue await asyncio.sleep(3) in a loop.

Note that to use timeouts and task cancellation you still need a firmware build with PR3380: https://github.com/micropython/micropython/pull/3380.

uasyncio.core 1.7 and uasyncio 1.4 were released with support for wait_for() call (timeout functionality).

UDP module is added: https://pypi.python.org/pypi/micropython-uasyncio.udp , https://github.com/pfalcon/micropython- ... p/uasyncio