Re: Should weak counted reference be able to be strengthened?

[Natasha Kerensikova <lithiumcat@instinctive.eu>]

On 2014-11-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Sat, 22 Nov 2014 09:57:05 +0000 (UTC), Natasha Kerensikova wrote:
>> generic
>>    type Held_Data (<>) is limited priavte;
>> package Natools.References is
>>    [...]
>> private
>>    type Data_Access is access Held_Data;
>
> This won't work. A pool-specific pointer should be the package's parameter,
> since the objects are allocated outside the package, aren't they?

They aren't. I find it much easier to deal with memory in the private
parts of a single package.

References are normally created using:

   function Create
     (Constructor : not null access function return Held_Data)
      return Reference;


(To be perfectly honest, I later added an access based constructor where
the client performs the allocation, but only to prevent an internal copy
from the function return to the allocated memory in a non-limited large
object instance (large enough to have the program OOM-killed when using
an internal copy, while an external build-in-place fits in the target
system memory).
You can inspect the whole code at
https://github.com/faelys/natools/blob/trunk/src/natools-references__protected.ads
)

>> However, what are the serious problems I'm supposed to have?
>> I have used this implementation with task types, but I have yet to
>> encounter any.
>
> The problem is that when you deallocate a task that is not yet terminated.
> A typical code deallocating tasks looks like:
>
>    T.Shut_Down; -- Go away!
>    while not T'Terminated loop -- Still here?
>       delay 0.01;
>    end loop;
>    Free (T); -- We are ready now
>
> This is basically the same issue as with your Reference type which may
> outlive the object. So are some internal things associated with the task,
> which may outlive the object deallocated when the access-to-task is freed.
>
> This is a complicated design with no reason (in case of tasks, there is a
> reason). Why should reference outlive the object?

How could a reference outlive the object?
The object is deallocated only in the Finalize of the last reference.


Natasha