[foreign] Pulling the string on Scope

[Jorn Vernee]

> 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.

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