[foreign] Pulling the string on Scope

[Maurizio Cimadamore]

On 22/12/2018 00:56, Jorn Vernee wrote:
>> Then, the short-lived scope S1 is closed, and its single resource (R1)
>> is collected. But what does that mean? If we really free R1, then we
>> end up making R2 dead as well, even though that was in another scope -
>> that means that the operation that the client did (assign R2 to S2,
>> presumably to extend its life-cycle) has been rendered useless.
>
> Sure, this is the intended behaviour I thought.
>
> e.g. if we have a pointer to a single element of on array (R2), and we 
> free the whole array (R1) we want the pointer to the single element to 
> be dead as well right? If the user wants to keep R2 alive, they should 
> not free R1. However, when R2 is closed R1 is still alive. Since R2 
> will be dependent on R1, but not vice-versa.

I certainly get where you are coming from. My claim here was that an API 
that allows you to move/free resources at the Pointer granularity is a 
'bad' API, in that it suggests an operation that is not really possible 
(at least not w/o some side-effects in the general case).

Maurizio

>
> Jorn
>
> Maurizio Cimadamore schreef op 2018-12-22 00:52:
>> On 20/12/2018 21:32, Jorn Vernee wrote:
>>
>>>> I think that could be ok as long as there's, as you say, one
>>>> memory region per
>>>> resource - but what if we want more resources to share the same
>>>> region? Do we really want to allocate a new memory region every
>>>> time
>>>> we allocate a new pointer?
>>>
>>> We don't allocate a new memory region every time. I have created a
>>> BoundedMemoryRegion subclass that can have another region as a
>>> dependency. So, for instance when accessing an element of an array I
>>> just create a BoundedMermoryRegion that is dependent on the
>>> BoundedMemoryRegion of the array, but not actually allocates any new
>>> native memory. If the array's BoundedMemoryRegion is closed, the
>>> dependent region will also no longer be alive.
>>
>> The reason I asked is that if you have a 1-N mapping between region
>> and resources (e.g. one region can spawn multiple resources) but what
>> you move to/from Scopes are resources, you still have issues.
>>
>> Let's say that I have a region M with resources R1 and R2.
>>
>> Initially both R1 and R2 belongs to scope S1.
>>
>> After a while, you decide to assign R2 to a more long-lived scope S2.
>> So now S1 has R1 and S2 has R2.
>>
>> Then, the short-lived scope S1 is closed, and its single resource (R1)
>> is collected. But what does that mean? If we really free R1, then we
>> end up making R2 dead as well, even though that was in another scope -
>> that means that the operation that the client did (assign R2 to S2,
>> presumably to extend its life-cycle) has been rendered useless.
>>
>> If, on the other hand, we do not collect R1, we end up with a (small)
>> leak. And extra complexity to keep track dependencies between
>> resources (reference counting?)
>>
>> In general with the model with you suggest, it seems like the
>> lifecycle of a resource has now two masters - scopes and memory
>> region, and that seems to create more complexity.
>>
>> Stepping back, I'm more and more convinced that the Scope abstraction
>> is doing way too many things at once (and this has been brought up
>> before by John and others). It seems like Scope is the API that does
>> allocation, as well as the API that manages life-cycles. If we zoom in
>> on allocation, we find two different levels of allocation: low level
>> memory region allocation, and high level allocateXYZ functionalities.
>> I'll cover this in an email that I will send in a separate thread, as
>> i don't want to overlap discussions too much.
>>
>> Cheers
>> Maurizio