I still don't see an issue. Unix port of course supports non-blocking I/O for example. MicroPython internal APIs also support non-blocking mode, and it's simply up to the ports to use it. As not many people used it so far, fixes are still made, e.g.: https://github.com/micropython/micropyt ... fbf1efeccakfricke wrote:That's rather peculiarly formulated question - what "major platforms" do you mean?Question: Is this correct, or does some of the major platforms not support non-blocking-/async-IO on the network socket?
- STM HAL
- CC3200
- Unix (and Android)
- ESP8266
- PIC 16-Bit
And socket (and in general, file/stream) non-blocking API is pretty easy: if it's not possible to read/write, return with EAGAIN error on lower level, which will translate to returning None with higher-level stream functions (.read()/.write()).
There's however another part to support async I/O - being able to wait on file-like objects/streams for data available and other events. I may imagine that part is much less consistent. For example, micropython-lib provides Linux-specific, the most efficient epoll() support, while stmhal provides POSIX poll inspired mechanism, which still deviates from it.
Either way, there're mechanisms available, but they are: 1) should be made more consistent across ports (there's big gap between baremetal and unix, unfortunately - we've let it be that, despite maintainers being well aware that's bad thing); 2) actual leveraging of those mechanisms are up to ports and their maintainers/community.
kfricke, if you're interested in this, and helping to progress this area, please finish your research/comparison how it works across different ports, and write it down somewhere (wiki page would be better than forum). That will be good initial data to work off.