Race condition between wait_for and socket.read()
Port, board and/or hardware
esp32 esp32c6-devkit-c1
MicroPython version
v1.25.0
Reproduction
await asyncio.wait_for(socket.readexactly(1), 0.01)
Expected behaviour
Either a timeout occurs, or 1 byte is read from socket
Observed behaviour
Occasionally, both 1 byte is read AND immediately timeout occurs. leading to data loss, since Timeout Exception prevents the read byte from being available to the application.
Additional Information
Possibly related to #7386 and #8717
Code of Conduct
Yes, I agree
Possible race condition failure in uasyncio wait_for/wait_for_ms
I'm seeing an issue using wait_for_ms() on reads from a socket, on ESP32 devices with recent HEAD, where occasionally I get an uncaught task CancelledError logged to the terminal and the wait_for_ms() never returns, locking up my code.
I'm using UDP sockets, so I'm not using the built-in Stream stuff, instead I'm rolling my own using the same underlying yield core._io_queue.queue_read() trick.
I suspect that it's triggered by a packet arriving at the same time as the wait ending, but I've had a gander at the uasyncio code and I can't see any obvious logic errors.
I'm using an ugly workaround at the moment (ditching the IOQueue and just repeatedly attempting to read from a non-blocking socket) as I have to have this code working this week, but I'll try to get back to it next week and see if I can reduce it to a smaller failing case and work out what's going wrong.