Hacker News Reader

Comment by kbd | Hacker News Reader

One of their issues was that Python runs a final GC call before process exit. Why does Python run that final GC call if the process is exiting anyway?

View on HN

Perhaps it's to make sure all the objects' finalizers are run also, making sure to release everything, not just memory and file descriptors? The finalizers are user-defined, so could include side effects that the GC would not know about.

Do they need to be run in a specific order? Could you maintain a linked list of all objects, and at exit go through it at exit and run the finalizes? Might be faster than actually reclaiming the memory as well.

Maintaining that list through the whole process duration just to use it in the end sounds expensive, both in CPU and memory terms.

Does Python guarantee that finalizers are called at all? Most languages don't, I thought.

I know Haskell does: https://hackage.haskell.org/package/base-4.9.1.0/docs/Foreig... I'm not sure finalizers make sense without a guarantee they will eventually be called. But Haskell, for example, makes no guarantees about when it will be called, between the moment the last reference is lost and the moment the program exits.

Python seems to, too: https://docs.python.org/3/library/weakref.html, "When the program exits, each remaining live finalizer is called unless its atexit attribute has been set to false. They are called in reverse order of creation."

PEP 442 describes the situation with good detail, including how it was in Python 2 and how Python 3 improves on it:

https://www.python.org/dev/peps/pep-0442/

In fact, this is now fixed in Python 3.6. When gc is disabled by the user, the final collection is not done.

The effect is faster shutdown with less "copy on read" but some __del__ methods and finally: blocks in some generators might never get called.

Reply on news.ycombinator.com