RFC: Proposal: Deterministic Object Destruction

[Richard Damon]

On 3/3/18 12:43 PM, Chris Angelico wrote:
> On Sun, Mar 4, 2018 at 4:37 AM, Richard Damon <Richard at damon-family.org> wrote:
>> On 3/3/18 11:33 AM, Michael Torrie wrote:
>>> On 03/03/2018 09:02 AM, ooomzay at gmail.com wrote:
>>>> I can assure you that RAII does what it says on the tin and is relied on
>>>> in
>>>> many critical systems to release resources robustly ... given the
>>>> pre-requisite deterministic destruction.
>>> Sure but did you read what Paul Moore wrote?  He said RAII works in C++
>>> because objects are allocated on the *stack* with strict lifetimes and
>>> scopes. They won't ever have cycles and they are guaranteed to be
>>> destroyed no matter what as the stack is unwound.  Python has no
>>> stack-allocated objects.
>>>
>>> In C++, Heap-allocated objects must still be managed manually, without
>>> the benefit of RAII, for much of the same reasons as people are giving
>>> here for why RAII is not a good fit for Python.  There are smart pointer
>>> objects that try to give RAII semantics to heap-allocated objects, with
>>> varying degrees of success. In other words there are some limitations.
>>>
>>> Python does not have stack-allocated objects, so the same issues that
>>> prevent RAII from automatically applying in C++ to heap objects exist
>>> here.
>>
>> Yes, stack allocated object in C++ have a nice lifetime to allow RAII to
>> work, but it doesn't just work with stack allocated objects. A lot of RAII
>> objects are members of a class object that may well be allocated on the
>> heap, and RAII makes sure that all the needed cleanup gets done when that
>> object gets destroyed.
> How do you guarantee that the heap object is properly disposed of when
> you're done with it? Your RAII object depends 100% on the destruction
> of the heap object.
>
> ChrisA

Yes, the heap object 'owns' a resource, and as long as that heap object 
exists, the resource needs to exist, but as soon as it doesn't, you want 
that resource freed.

That heap object might well be controlled by some other RAII object 
(maybe a smart pointer with a ref count) or maybe that object is being 
manually controlled by the program. But the key is that when it goes 
away, all of the resources it controls via RAII are automatically 
cleaned up, and you don't need all that cleanup made explicit in the 
owning class.

If the resource is plentiful, like memory, we can simplify the life 
management by using something like garbage collection, so if some is 
used longer than needed it isn't a big issue. Other resources are much 
more valuable and limited, and it is important to release them when no 
longer needed. Without some method to make sure that happens 
'automatically' as soon as possible, it requires that the programmer 
explicitly deal with it in full detail.

Now, a lot of talk has been throw around about things like reference 
cycles getting in the way of this, but practically, the resources that 
this would be needed for, then not to get involved in those sorts of 
issues, but tend to live in more simple structures, so the fact that 
objects in a cycle might need for the garbage collector to determine 
they aren't used anymore isn't an issue (and the presence of garbage 
collection says that these more complicated structures, which only hold 
resources that are plentiful, don't need to be precisely managed will 
RAII controls).

-- 
Richard Damon