Andrew Svetlov <andrew.svet...@gmail.com> added the comment:
Not sure if failed uvloop tests are correct. The scenario is like the following: 1. Suppose we have an unblocking socket connected to peer. 2. Create a task for reading data: task = asyncio.create_task(loop.sock_read(sock, 1)) Note, the task is not started yet. 3. Just after it, cancel the task without waiting for the actual cancellation task.cancel() 4. Finally, read from the socket again: data = await loop.sock_read(sock, 1) If I put context switch (await asyncio.sleep(0)) between 3) and 4) *or* replace direct sock_read() call in 4) with creation a task (data = await asyncio.create_task(loop.sock_read(sock, 1))) the cancellation of former read is performed and test passes. I very doubt if any sane code is organizing like this test: start delayed reading, cancel it and read again. The worse, neither previous not current sock_read() implementation doesn't prevent the concurrent reading which basically delivers data in an unpredictable order. Honestly, I'm not sure if we need to provide the concurrency guarantee for such low-level functions. The code built on top of these low-level primitives should handle the cuncurrent access problem IMHO. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30064> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
