You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description of the bug
When a loop ends and leaves behind objects, collecting them after a new loop starts transfers state between the two loops. This is because usim objects interact with the "current" event loop; delayed cleanup means the current loop is the wrong one.
How To Reproduce
No repro yet. Encountered this in lapis when cleaning an async generator is cleaned up.
Expected behavior
Objects should not leak. We might have to register objects and explicitly clean them up. Keep in mind that not registering was an explicit design decision to avoid overhead; if needed, restrict it to objects that need it.
Consider sys.set_asyncgen_hooks to link async generators (the most likely culprit) to the event loop.
Consider gc.collect whenever a loop finishes and/or starts.
The text was updated successfully, but these errors were encountered:
Description of the bug
When a loop ends and leaves behind objects, collecting them after a new loop starts transfers state between the two loops. This is because
usim
objects interact with the "current" event loop; delayed cleanup means the current loop is the wrong one.How To Reproduce
No repro yet. Encountered this in
lapis
when cleaning an async generator is cleaned up.Expected behavior
Objects should not leak. We might have to register objects and explicitly clean them up. Keep in mind that not registering was an explicit design decision to avoid overhead; if needed, restrict it to objects that need it.
sys.set_asyncgen_hooks
to link async generators (the most likely culprit) to the event loop.gc.collect
whenever a loop finishes and/or starts.The text was updated successfully, but these errors were encountered: