This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author asvetlov
Recipients abacabadabacaba, asvetlov, ned.deily, yselivanov
Date 2019-12-08.16:37:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1575823041.31.0.0737945344707.issue30064@roundup.psfhosted.org>
In-reply-to
Content
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.
History
Date User Action Args
2019-12-08 16:37:21asvetlovsetrecipients: + asvetlov, ned.deily, abacabadabacaba, yselivanov
2019-12-08 16:37:21asvetlovsetmessageid: <1575823041.31.0.0737945344707.issue30064@roundup.psfhosted.org>
2019-12-08 16:37:21asvetlovlinkissue30064 messages
2019-12-08 16:37:21asvetlovcreate