November 12, 2025
Garbage Collector Jump Scare
Async and Finaliser Deadlocks
A Python cleanup locks up, Rust fans yell “not async” as dupe police roll in
TLDR: A Python cleanup example shows how hidden “finalizer” code can deadlock by grabbing a lock at the worst moment. Commenters fought over whether it’s really async, while Rust folks argued the real “futurelock” drama is about cancellation safety, not finalizers—important because surprise cleanup can silently freeze apps.
A tiny Python demo tried to clean up an object, grabbed a lock, and then… froze. The author uses this to explain a sneaky trap: finalizers (the cleanup code that runs when stuff is thrown away) can fire at surprise times and jam your program. The crowd instantly split into camps. One camp waved the “this isn’t async” flag, with wrcwill insisting the delete call is just normal code executing. Another camp said the bigger drama is Rust’s “futurelock,” where canceled tasks can leave things half-done—very different from Python’s cleanup-on-delete. Nemothekid basically shouted: wrong villain, this is about cancellation safety, not finalizers. Meanwhile, hinkley wrote a mini-essay about two styles of asynchronous programming (doing tasks step-by-step vs. breaking them into state machines) and how locks can starve everything if you hold them too long. Over in the meta corner, aw1621107 dropped a classic Dupe alert and linked the original thread here, sparking groans and eye-rolls. Jokes flew: “garbage collector jump scare,” “Schrödinger’s lock: held and hungry,” and “never trust del at 2 a.m.” Through the noise, most agreed on one thing: hidden cleanup code running at surprise times is how apps end up ghosted by their own locks. Keeganpoppen? Just vibes: “props to the author.”
Key Points
- •A Python example demonstrates a deadlock when a finalizer (__del__) tries to acquire a lock already held by the main thread.
- •CPython’s reference counting calls __del__ immediately after t = None, interleaving finalizer execution on the same thread.
- •Removing t = None or changing references alters finalizer timing and can avoid the deadlock.
- •Finalizers run at runtime-chosen times and can interact with shared state, requiring non-local reasoning.
- •The scenario is presented as a simplified instance of issues underlying Rust’s “futurelock” bug related to async behavior.