RFC: Proposal: Deterministic Object Destruction
On Monday, 5 March 2018 19:14:05 UTC, Paul Rubin wrote:
> Ooomzay writes:
> > If you want to use RAII objects then you will make sure you avoid
> > adding them to orphan cycles by design. If you don't know how to do
> > that then don't write applications that manage critical resources.
> My claim is managing critical resources with refcounts is bug-prone in
> the case where the refcounts can become arbitrarily large at runtime.
What case is that? Don't go there! You may be jaded because python forgives
bad design practices and peeps are inclined to leak resources all over
the place for no good reason whatever and then complain when they have
trouble cleaning up or exiting!
> You say you wrote a program that worked that way, but it sounds
> horrendous and I'd like to know how you tested it, maintained it, kept
> it maintainable by other programmers, etc.
> It's painful to even think about.
I too used to suffer pain with python - until I saw that light and
worked out how to use it for RAII. So here's the keys for much less pain:-
* Use CPython (or C++ ;)
* Use RAII for every resource-holding class: Implement __del__ to release any resources acquired in __init__. (This is significantly less effort, and more reliable than adding __enter__ & __exit__ to every class).
* Wrap your try-except blocks in functions to prevent exceptions persisting outside the handler because in python they leak. This is typically a very natural factorization.
* Take care not to create Cyclic Exceptions in your Exception handling logic.
This was the one that had me scratching my head for a couple of hours the first
time I inadvertantly created a cycle.
* If you have no application-level requirement for persistent orphan cycles,
and few, if any, applications do, then disable gc on entry and raise an
exception on exit, or any other convenient moment if there is any garbage
to be collected.
* Immediately plug/bug any leaks that you discover. Do not let them build
up or you will drown and loose faith that there can be a better way.