I found out what was the problem. The behavior of my "reader" (The callback passed to AbstractEventLoop.add_reader()) is to set an event. This event is awaited for in a coroutine which actually reads what is written on a pipe. The execution flow is the following:
* NEW LOOP TURN * The selector awaits for read-ready state on a file descriptor AND The coroutine awaits for the event * At some point, the file descriptor becomes read-ready, the selector queue the callback to set the event on the loop * The callback put on the queue is called and the event is set * NEW LOOP TURN * The selector awaits for read-ready state on a file descriptor AND The coroutine awaits for the event * The file descriptor is read-ready, so the selector queue the callback to set the event on the loop * The corouting is resumed, because the event is now set, the corouting then reads what was written on the file descriptor, then clears the event and awaits again for it * The callback put on the queue is called and the event is set * NEW LOOP TURN * The selector awaits for read-ready state on a file descriptor AND The coroutine awaits for the event * The corouting is resumed, because the event was set at the end of the last turn, so the coroutine attempts a read, but blocks on it, because the file descriptor is actually not read-ready Rince and repeat. This behavior actually depends on how the loop is implemented. So the best practice here is to actually do the read from the callback you gives to AbstractEventLoop.add_reader(). I think we should put a mention about it in the documentation. -- https://mail.python.org/mailman/listinfo/python-list
