RFC: Proposal: Deterministic Object Destruction

[Richard Damon]

On 3/3/18 1:28 PM, Chris Angelico wrote:
> On Sun, Mar 4, 2018 at 5:22 AM, Richard Damon <Richard at damon-family.org> wrote:
>> 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.
> You're trying to handwave away the *exact point* that we are all
> making: EVERY object in Python is a heap object. So how is your magic
> wand going to make any of this work? You have to do it exclusively
> with heap objects because there is nothing else available.
>
> ChrisA

Because while every OBJECT in Python is on the heap, not every THING is, 
as you do have local and global names bound to those objects.

This is like in C++, in C++ there is no way to directly reference an 
object on the heap, but need to use a stack or statically allocated 
object or reference (which has a name) to get to it.

The fact that all objects exist on the heap actually makes some things 
simpler, in C++ you need to be careful with smart pointers that they 
only point to objects on the heap, and thus are delete-able. If you 
accidentally put the address of a static or stack based object into one 
of them (and don't add a fake reference to the count) you will run into 
an issue when the reference count goes to zero and you try to destroy 
and then free the memory for the object. In Python, that can't happen.

-- 
Richard Damon