Repository navigation
Closed
Labels
3.10 (EOL)end of lifeend of life3.9 (EOL)end of lifeend of lifetopic-asynciotype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/asvetlov'
closed_at = None
created_at = <Date 2017-04-13.08:55:09.854>
labels = ['type-bug', '3.9', '3.10', 'expert-asyncio']
title = "BaseSelectorEventLoop.sock_{recv,sendall}() don't remove their callbacks when canceled"
updated_at = <Date 2020-06-15.16:37:16.856>
user = 'https://bugs.python.org/abacabadabacaba'bugs.python.org fields:
activity = <Date 2020-06-15.16:37:16.856>
actor = 'vstinner'
assignee = 'asvetlov'
closed = False
closed_date = None
closer = None
components = ['asyncio']
creation = <Date 2017-04-13.08:55:09.854>
creator = 'abacabadabacaba'
dependencies = []
files = ['49146']
hgrepos = []
issue_num = 30064
keywords = ['patch']
message_count = 41.0
messages = ['291593', '326294', '329746', '355272', '355273', '357989', '358011', '358098', '358108', '362637', '362671', '362690', '368553', '368701', '368702', '370123', '370131', '370143', '370147', '370159', '370161', '370205', '370215', '370218', '370219', '370234', '370268', '370269', '371240', '371247', '371467', '371478', '371479', '371485', '371489', '371490', '371491', '371492', '371495', '371498', '371499']
nosy_count = 9.0
nosy_names = ['fantix', 'ned.deily', 'asvetlov', 'abacabadabacaba', 'lukasz.langa', 'yselivanov', 'achimnol', 'miss-islington', 'aeros']
pr_nums = ['10419', '20369', '20460', '20485', '20487', '20494', '20503', '20868', '20869']
priority = 'high'
resolution = None
stage = 'commit review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue30064'
versions = ['Python 3.9', 'Python 3.10']Metadata
Metadata
Assignees
Labels
3.10 (EOL)end of lifeend of life3.9 (EOL)end of lifeend of lifetopic-asynciotype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Projects
- StatusShow more project fieldsDone
Activity
abacabadabacaba commentedon Apr 13, 2017
Code:
Result:
1st1 commentedon Sep 24, 2018
See also https://bugs.python.org/issue34795
asvetlov commentedon Nov 12, 2018
New changeset 7438792 by Andrew Svetlov in branch 'master':
bpo-30064: Refactor sock_* asyncio API (bpo-10419)
7438792
1st1 commentedon Oct 23, 2019
I think this broke asyncio a bit. These two uvloop sock_* API tests no longer pass on asyncio 3.8:
https://github.com/MagicStack/uvloop/blob/master/tests/test_sockets.py#L192
https://github.com/MagicStack/uvloop/blob/master/tests/test_sockets.py#L238
Andrew, since this was your patch, please take a look.
1st1 commentedon Oct 23, 2019
I'll elevate the status so that we don't forget before 3.8.1 is too close
ned-deily commentedon Dec 7, 2019
Andrew, Yury: ping. 3.8.1 cutoff is approaching.
asvetlov commentedon Dec 8, 2019
Not sure if failed uvloop tests are correct.
The scenario is like the following:
task = asyncio.create_task(loop.sock_read(sock, 1))
Note, the task is not started yet.
task.cancel()
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.
ambv commentedon Dec 9, 2019
Note: this is going to miss Python 3.8.1 as I'm releasing 3.8.1rc1 right now. Please address this before 3.8.2 (due in February).
27 remaining items
aeros commentedon Jun 14, 2020
No problem at all, and thanks for clarifying.
That seems reasonable to me and would make the most sense at a glance. If this is confirmed to be the source of the issue, we should be able to just reduce the size of the socket's send buffer via SO_SNDBUF before sending to it so that it fills up much more quickly.
fantix commentedon Jun 14, 2020
OK I think I solved the problem by improving the two loops using smarter buffer sizes:
and
This test is now running ~25x faster, and the load test crashed my laptop a few times before it hits a timeout.
Last question before PR pls: given the fact that this test is to cover a fixed case when loop.sock_*() was hanging forever, should I keep the wait_for(..., timeout=10)?
fantix commentedon Jun 14, 2020
and yes, updated the SO_SNDBUF too
aeros commentedon Jun 14, 2020
For now, I think we can keep the asyncio.wait_for() w/ 10 the sec timeout. I'll have to run the tests locally though w/ the patch to double check (once the PR is opened), and it may still end up needing to be increased if the test fails again in the future. It should be okay though.
miss-islington commentedon Jun 14, 2020
New changeset 8f04a84 by Fantix King in branch 'master':
bpo-30064: Fix slow asyncio sock test (GH-20868)
8f04a84
miss-islington commentedon Jun 14, 2020
New changeset 83cd968 by Miss Islington (bot) in branch '3.9':
bpo-30064: Fix slow asyncio sock test (GH-20868)
83cd968
aeros commentedon Jun 14, 2020
Thanks again for working on this @fantix, and for the continued vigilance on the issue after the test failures occurred in the buildbots. I think this recent PR-20868 will do the trick. At the very least, it will make the failure much more rare than before, which is definitely an improvement.