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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,7897733b1978b6a4
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.28.135 with SMTP id b7mr4580620pbh.8.1321616502806;
        Fri, 18 Nov 2011 03:41:42 -0800 (PST)
Path: 
 h5ni5279pba.0!nntp.google.com!news2.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!news.musoftware.de!wum.musoftware.de!news.weisnix.org!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Fri, 18 Nov 2011 12:41:41 +0100
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Freezing a task
References: <32992849.648.1321544004241.JavaMail.geo-discussion-forums@vbmh5>
 <m2k46yagdq.fsf@pushface.org> <mzm6z5dir1ee$.1b36kl4upye4x$.dlg@40tude.net>
 <32201299.75.1321579435782.JavaMail.geo-discussion-forums@yqbl36>
 <1ffqisv4jbhfl$.qceqrbo8tnl2$.dlg@40tude.net> <m2bos9agq1.fsf@pushface.org>
In-Reply-To: <m2bos9agq1.fsf@pushface.org>
Message-ID: <4ec64475$0$6575$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 18 Nov 2011 12:41:41 CET
NNTP-Posting-Host: aef36f77.newsspool3.arcor-online.net
X-Trace: 
 DXC=LS\W6IE1ODI0YVY]kmLTlDMcF=Q^Z^V3H4Fo<]lROoRA8kF<OcfhCOKEUk<]:HK63Anc\616M64>JLh>_cHTX3jMX6nQ1^mm3PF
X-Complaints-To: usenet-abuse@arcor.de
Xref: news2.google.com comp.lang.ada:14454
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Date: 2011-11-18T12:41:41+01:00
List-Id: <comp.lang.ada>

On 18.11.11 11:05, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> however, I would use an exception rather than output parameter
> 
> I like that. Will give it strong consideration for a design update (of
> course, it wouldn't do for a SPARK implementation; personally I'd like
> to see SPARK allow provably-handled exceptions (though I suspect the
> problem is with "provably")).

In case I want an interrupt to stop (and release) the task,
will an exception, such as Pending_Abort from the example,
work? Because, IIUC, when the protected procedure handling the
interrupt raises Pending_Abort, then this has no effect
(as the procedure is a handler, LRM C.3(7)). Is this correct?

Maybe the handler procedure might just adjust the status of
the object so as to take note of the interrupt.
When the task then calls an entry such as Get from the example,
and the entry raises an exception, it will have an effect. But then,
this will interrupt the task only later...