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 mikeshardmind
Recipients asvetlov, mikeshardmind, yselivanov
Date 2020-02-18.03:49:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1581997795.53.0.449843151163.issue39232@roundup.psfhosted.org>
In-reply-to
Content
Linking out to a real-world example where this still manages to happen after running the event loop for an entire 2 seconds waiting for transports to close themselves after finishing everything else:

https://github.com/Cog-Creators/Red-DiscordBot/issues/3560

As well as what we're currently looking at for a temporary solution for this at this point:

https://github.com/Cog-Creators/Red-DiscordBot/pull/3566


I looked into what would need to change to handle this in CPython, but am not confident in my ability to make such a PR after doing so, at least not without more discussion about it.

The best solution I considered involves making the only public way to make transports be tied to an event loop which hasn't been closed yet, and ensuring the event loop keeps a reference to each of these so that it can deterministically close them at loop finalization. Searching GitHub alone found that this would break way too many things.

If this can't be fully fixed, a solution which at least ensures this can't cause an uncatchable exception would be appreciated.
History
Date User Action Args
2020-02-18 03:49:55mikeshardmindsetrecipients: + mikeshardmind, asvetlov, yselivanov
2020-02-18 03:49:55mikeshardmindsetmessageid: <1581997795.53.0.449843151163.issue39232@roundup.psfhosted.org>
2020-02-18 03:49:55mikeshardmindlinkissue39232 messages
2020-02-18 03:49:54mikeshardmindcreate