Message362174
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. |
|
Date |
User |
Action |
Args |
2020-02-18 03:49:55 | mikeshardmind | set | recipients:
+ mikeshardmind, asvetlov, yselivanov |
2020-02-18 03:49:55 | mikeshardmind | set | messageid: <1581997795.53.0.449843151163.issue39232@roundup.psfhosted.org> |
2020-02-18 03:49:55 | mikeshardmind | link | issue39232 messages |
2020-02-18 03:49:54 | mikeshardmind | create | |
|