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 aaliddell
Recipients Elvis.Pranskevichus, Nikita Ilyasov, aaliddell, asvetlov, chris.jerdonek, lukasz.langa, miss-islington, ods, yselivanov
Date 2021-05-13.15:20:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Wrapping every resource allocating call like that is what we were trying to avoid, since it makes wait_for go from a simple one-line helper to something you have to be very careful with.

Conceptually, a user should expect that wait_for should behave the exact same as awaiting the underlying awaitable, just with auto-cancellation. The problem with the current wait_for is that there is a gap where the underlying task may have completed but a cancellation arrives. In this case, we need to raise the cancellation to be a good asyncio citizen, but the underlying task has no opportunity to act on the cancellation (to free the resource) since it is already complete and cannot be re-entered. So the resource returned by the completed task gets stuck in limbo, since we can't return it and we can't assume a generic 'close' behaviour.

See my comment in the PR for a suggestion about an alternative structure for wait_for, which may avoid this gap and hence prevent the leak (but I have not tested it!)
Date User Action Args
2021-05-13 15:20:09aaliddellsetrecipients: + aaliddell, ods, asvetlov, chris.jerdonek, Elvis.Pranskevichus, lukasz.langa, yselivanov, miss-islington, Nikita Ilyasov
2021-05-13 15:20:09aaliddellsetmessageid: <>
2021-05-13 15:20:09aaliddelllinkissue37658 messages
2021-05-13 15:20:09aaliddellcreate