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!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.stack.nl!zen.net.uk!dedekind.zen.co.uk!news.netfront.net!not-for-mail
From: "Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org>
Newsgroups: comp.lang.ada
Subject: Re: Reference counting and idempotent finalize
Date: Wed, 11 Sep 2013 05:21:46 -0700
Organization: Netfront http://www.netfront.net/
Message-ID: <l0pn8q$rih$1@adenine.netfront.net>
References: <slrnl30ie3.1lme.lithiumcat@sigil.instinctive.eu>
NNTP-Posting-Host: 24.73.142.22
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: adenine.netfront.net 1378902106 28241 24.73.142.22 (11 Sep 2013
 12:21:46 GMT)
X-Complaints-To: news@netfront.net
NNTP-Posting-Date: Wed, 11 Sep 2013 12:21:46 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130801 Thunderbird/17.0.8
In-Reply-To: <slrnl30ie3.1lme.lithiumcat@sigil.instinctive.eu>
Xref: news.eternal-september.org comp.lang.ada:17157
Date: 2013-09-11T05:21:46-07:00
List-Id: <comp.lang.ada>

On 09/11/2013 03:45 AM, Natasha Kerensikova wrote:
>          Access_Value.all.Counter := Access_Value.all.Counter - 1;

What happens if Counter is already zero? Can Counter become negative, and if so, what does it mean for Counter to be 
negative?

> I neglected the possibility of exceptional flow interruption because I
> felt that an exception in Finalize triggers the end of the world (the
> same way I've felt for a long time the idempotency requirement). Now
> having done the research, 7.6.1(13) doesn't really mention the world
> ending, that looks quite close to it, doesn't it?

ARM 7.6.1 says, "It is a bounded error for a call on Finalize or Adjust that occurs as part of object finalization or 
assignment to propagate an exception." My practice has, therefore, been to always ensure that Finalize cannot propagate 
an exception.

FWIW, Finalize from PragmARC.Safe_Pointers looks like

    procedure Finalize (Item : in out Safe_Pointer) is
       procedure Free is new Ada.Unchecked_Deallocation (Object => Safe_Group, Name => Name);
    begin -- Finalize
       if Item.Ptr /= null then
          if Item.Ptr.Count > 0 then
             Item.Ptr.Count := Item.Ptr.Count - 1;
          end if;

          if Item.Ptr.Count = 0 then
             Free (Item.Ptr);
          end if;

          Item.Ptr := null;
       end if;
    end Finalize;

I have convinced myself that this cannot propagate an exception (except Storage_Error, of course, since anything can 
result in Storage_Error). It might be easier (and safer) to always have "exception when others => null;" on every Finalize.

The PragmAda Reusable Components, including the full implementation of PragmARC.Safe_Pointers, are at

pragmada.x10hosting.com

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python and the Holy Grail

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---