4 ms·
Does anyone understand why the event loop only keeps weak references to tasks? It'd seem wise to do something to stop it from being garbage collected while runn
by NelsonMinar 4y ago
Does anyone understand why the event loop only keeps weak references to tasks? It'd seem wise to do something to stop it from being garbage collected while running, maybe also while waiting to run.
- masklinn 4y agoOnly guess I’d have is to protect the system against infinite-loop tasks, but I don’t remember any other runtime caring and an a task which never terminates seems easier to diagnose than one which disappears on you.
- kortex 4y agoBecause it's almost always the case that the consumer is going to keep a reference to the task in some way, so that is the logical choice for the "primary owner" of the task. Python doesn't have ownership per se like rust, but if you keep more than one hard reference to an object around, it'll prevent collection, so in cases such as this it makes sense to designate one primary owner and have all other references be weakref.
- skitter 4y ago> if you keep more than one hard reference to an object around, it'll prevent collection Which is the behavior the parent comment asks for.
- kevin_thibedeau 4y agoThat creates a new problem that you have to remember to kill unwanted threads.
- deleted 4y ago[deleted]
- JonChesterfield 4y agoPython's reference counted - if the event loop holds a reference until the task has run, then drops it, then everything behaves sanely. That's not a cycle. It just means the task that was scheduled will execute, which seems like the right default.
- coopsmoss 4y agoI agree, I think this is very unpythonic behavior