From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Natasha Kerensikova <lithiumcat@instinctive.eu>
Newsgroups: comp.lang.ada
Subject: Re: Should weak counted reference be able to be strengthened?
Date: Sat, 22 Nov 2014 10:36:15 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <slrnm70pp4.nrc.lithiumcat@nat.rebma.instinctive.eu>
References: <slrnm6u770.nrc.lithiumcat@nat.rebma.instinctive.eu>
 <7d9r3whe43z8$.1f2l3n5cz0zh0$.dlg@40tude.net>
 <slrnm6uks1.nrc.lithiumcat@nat.rebma.instinctive.eu>
 <kywrzxvibzmw$.1h82z2coiciqh$.dlg@40tude.net>
 <slrnm6v0qi.nrc.lithiumcat@nat.rebma.instinctive.eu>
 <1h5a33dishpky.8m2rngmy7e7x$.dlg@40tude.net>
 <slrnm70nfm.nrc.lithiumcat@nat.rebma.instinctive.eu>
 <169juip09gkti$.5p7jlls4ehjz.dlg@40tude.net>
Injection-Date: Sat, 22 Nov 2014 10:36:15 +0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="76a49b86bc3e16725b7cfca3d85cb4c8";
	logging-data="8884"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19Dlb1+s9Q+9Shr94WwuSQX"
User-Agent: slrn/1.0.1 (FreeBSD)
Cancel-Lock: sha1:TluknXb6X8h+mxTaGXoiifieqUc=
Xref: news.eternal-september.org comp.lang.ada:23642
Date: 2014-11-22T10:36:15+00:00
List-Id: <comp.lang.ada>

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