Issue #2229: allow GCing of suspended coroutines #2230
Conversation
A suspended coroutine should be GCed if the underlying loop is closed and no other outside reference exists to it. However, a suspended coroutine with a refcycle would be kept alive by the _futures_to_runners mapping. Instead use a private attribute on the future.
|
Do you think it's just bad luck (travis-ci server load) that every build configurations of https://travis-ci.org/tornadoweb/tornado/builds/323627058 took more than twice as long as usual to run? |
|
@ploxiln I just noticed that. It seems Travis-CI is saturated these days. When I run the test suite locally, I don't get any runtime difference on the test suite between this PR and git master (17 seconds on both). Even Perhaps @bdarnell can restart the build at some point to see if runtimes vary. I don't have the access rights to do so. |
|
Now we're even getting "import timed out" errors: |
|
OK yeah it's just travis, nevermind me :) |
|
FTR, builds have also become awfully long on CPython. |
|
Thanks for this. I've got it rebased and squashed in #2248 with the change to AsyncIOMainLoop as a separate commit. This commit produced some log warnings at GC time that I spent some time hunting down. |
3 participants
A suspended coroutine should be GCed if the underlying loop is closed and no other outside reference exists to it. However, a suspended coroutine with a refcycle would be kept alive by the
_futures_to_runnersmapping. Instead use a private attribute on the future.