@jonaslorander I very well know Peter's excellent uasyncio tutorial. It is just that I wanted to coerce @pfalcon into writing something about uasyncio on the official Pyboard documentation pages; nothing else.
Today, I ran into the infamous umqtt hang problem. Peter again developed a workaround that I still need to try out.
However, this made me wonder whether this umqtt hang problem is somewhat related to the 100% CPU problem discussed previously in this thread? It seems to occur with while: pass loops, with or without uasyncio.
I have no hard facts to proof this, it is just a hunch; me thinking up loud. Perhaps testing the umqtt code on Unix could reveal what goes wrong?
Some problems with asyn library
-
pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: Some problems with asyn library
The hang problem is specific to ESP32. It does not occur on ESP8266 and the consensus is that it's an issue with the ESP32 vendor code. So it's unclear to me what would be proved by testing on Unix.
Regarding 100% CPU utilisation, the asyn and aswitch libraries are primarily intended for firmware applications. A busy-wait loop with await asyncio.sleep(0) is common practice in such applications and, in uasyncio, is the way to guarantee "fair round robin" scheduling. So I don't see the use of that technique as a problem.
The primitives in asyn are intended to behave similarly to their counterparts in CPython (where they exist). I would regard any failure to function in the Unix build as a bug. However if a busy-wait loop results in 100% CPU utilisation I'm unwilling to compromise the library's performance on firmware projects to fix it. The current drawn by a Pyboard is largely constant unless you invoke a low power mode.
I suggest that anyone wanting to optimise asyn for use on Unix creates a fork for that purpose.
The idea of a version of uasyncio supporting the STM "sleep" mode is interesting. But I have no plans to pursue it.
The asyn library is, for my purposes, complete and I have no plans for further work on uasyncio-related ideas. Except for bugfixes and testing against any future uasyncio updates.
Regarding 100% CPU utilisation, the asyn and aswitch libraries are primarily intended for firmware applications. A busy-wait loop with await asyncio.sleep(0) is common practice in such applications and, in uasyncio, is the way to guarantee "fair round robin" scheduling. So I don't see the use of that technique as a problem.
The primitives in asyn are intended to behave similarly to their counterparts in CPython (where they exist). I would regard any failure to function in the Unix build as a bug. However if a busy-wait loop results in 100% CPU utilisation I'm unwilling to compromise the library's performance on firmware projects to fix it. The current drawn by a Pyboard is largely constant unless you invoke a low power mode.
I suggest that anyone wanting to optimise asyn for use on Unix creates a fork for that purpose.
The idea of a version of uasyncio supporting the STM "sleep" mode is interesting. But I have no plans to pursue it.
The asyn library is, for my purposes, complete and I have no plans for further work on uasyncio-related ideas. Except for bugfixes and testing against any future uasyncio updates.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.