3 ms·

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?

by kbd 10y ago

conistonwater 10y ago
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.
- Paul-ish 10y ago
  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.
  - icebraining 10y ago
    Maintaining that list through the whole process duration just to use it in the end sounds expensive, both in CPU and memory terms.
- chris_7 10y ago
  Does Python guarantee that finalizers are called at all? Most languages don't, I thought.
  - conistonwater 10y ago
    I know Haskell does: https://hackage.haskell.org/package/base-4.9.1.0/docs/Foreign-ForeignPtr.html#v:newForeignPtr 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 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."
  - ambivalence 10y ago
    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/ https://www.python.org/dev/peps/pep-0442/
ambivalence 10y ago
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.

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?

by kbd 10y ago

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?

conistonwater 10y ago

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.

Paul-ish 10y ago
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.
- icebraining 10y ago
  Maintaining that list through the whole process duration just to use it in the end sounds expensive, both in CPU and memory terms.
chris_7 10y ago
Does Python guarantee that finalizers are called at all? Most languages don't, I thought.
- conistonwater 10y ago
  I know Haskell does: https://hackage.haskell.org/package/base-4.9.1.0/docs/Foreign-ForeignPtr.html#v:newForeignPtr 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 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."
- ambivalence 10y ago
  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/ https://www.python.org/dev/peps/pep-0442/

ambivalence 10y ago

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.