MicroPython Forum (Archive)

I have updated my micropython-async repo to provide information on the new uasyncio. This includes:

• A guide to syntax changes for porting code from V2.
• A revised tutorial.
• Code examples.
• Classes for debouncing switches and pushbuttons with callbacks.
• A retriggerable timer class (watchdog/monostable type object) with a callback.
• Synchronisation primitives.

The primitives provide CPython-compatible implementations of Queue, Semaphore, BoundedSemaphore and Condition. They aren't efficient but they will act as stand-ins until Damien releases optimised versions.

The material is a work-in-progress and rough round the edges, but should clarify some of the confusion.

Looking good, and thanks for all the work which went into this!

This is an awesome tutorial!
Thanks a lot for your efforts in porting all examples to the new version and writing that new tutorial!

I haven't read through everything in detail yet, but I found a paragraph that is not completely correct:

5.1 Exceptions

Where an exception occurs in a task, it should be trapped either in that task or in a task which is awaiting its completion. This ensures that the exception is not propagated to the scheduler. If this occurred the scheduler would stop running, passing the exception to the code which started the scheduler. Consequently, to avoid stopping the scheduler, tasks launched with asyncio.create_task() must trap any exceptions internally.

An exception only stops the scheduler if it occurs in the task created by *asyncio.run(task())* because this by definition only runs the scheduler until *task()* is finished.
If an exception occurs in a task created by *asyncio.create_task* then it will be handled by *Loop.default_exception_handler* and not stop the scheduler. Using a custom exception handler you can then log those uncaught exceptions.
Consequently starting the scheduler with *Loop.run_forever()* will result in the scheduler never being stopped (unless there is a bug in the scheduler itself).

Also it is therefore not neccessary to trap all exceptions. Actually the contrary is advisable in my opinion, at least for TimeoutErrors and CancelledErros. Reason: If a coroutine catches a cancellation error without raising it, the coroutine awaiting that task will never know what happened to the task it awaited.

Thanks so much Peter! Your asyncio documentation is a wonderful resource and I really appreciate the effort you've invested in a) writing it and b) keeping it up-to-date. Awesome work.

kevinkk525 wrote: ↑

Fri Apr 10, 2020 7:28 pm

...
I haven't read through everything in detail yet, but I found a paragraph that is not completely correct:
...

Thanks for that. I'll update that section. Re interception of timeouts and cancellation, you might know the answer to this issue. The question is whether it is possible for a coro to distinguish between its being cancelled or it timing out. So far I can't see how to do it.

I answered to the issue on github.
To provide an answer here too:

The explanation is that the coro/task is being cancelled. It doesn't matter why it is being cancelled (due to timeout or task cancellation or whatever reason you may come up with). Task.cancel() is being called and the coro sees a CancelledError.
So it will always see a CancelledError and not a TimeoutError. So you can't distinguish between the coro being cancelled because of Task.cancel() or a wait_for Timeout.

Only the caller of wait_for gets that distinction because only wait_for knows the reason for the cancellation of the task. (Basically not even the scheduler knows, it's just a variable inside wait_for).

@pythoncoder Thank you very much for you shared your code.I had been rebuilded the micropython firmware. how to porting to the uasyncio to the firmware.

If you build from up to date sources uasyncio will be included in the firmware. Alternatively install the latest daily build.

Thank you Peter, this is absolutely wonderful!!

Thanks Peter - a really great resource. Appreciate all the effort you put into this and maintaining it.