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.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,25642dc8f94534f6
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news4.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.80.MISMATCH!news.astraweb.com!border3.a.newsrouter.astraweb.com!news.netcologne.de!ramfeed1.netcologne.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Basic question about select
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: <Xns9D68C41D38649fdnbgui7uhu5h8hrnuio@188.40.43.213>
 <1p2m3s7y70lsa$.79fl3we9edva$.dlg@40tude.net>
 <hra886$nku$1@tornado.tornevall.net>
Date: Thu, 29 Apr 2010 00:41:10 +0200
Message-ID: <li4owy33qsdk$.1h1n04y4qjtme.dlg@40tude.net>
NNTP-Posting-Date: 29 Apr 2010 00:41:07 CEST
NNTP-Posting-Host: d436e73e.newsspool1.arcor-online.net
X-Trace: 
 DXC=dbhLm0Pa7efeoCI^f\Y]Eaic==]BZ:afn4Fo<]lROoRa<`=YMgDjhgb6E_NldJ1nGb[6LHn;2LCVn[<mhadbfdUk>HY>d<_f61jh=eUH]9_eia
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:11242
Date: 2010-04-29T00:41:07+02:00
List-Id: <comp.lang.ada>

On Wed, 28 Apr 2010 14:00:50 -0700, Jeffrey R. Carter wrote:

> Technically, though, it isn't quite true: if the entry call *completes* then the 
> abortable part (after "then abort") is aborted: "If the triggering_statement 
> completes other than due to cancellation, the abortable_part is aborted".

This is a very interesting question. I don't know if this wording indeed
requires the rendezvous and the abortable part to execute in parallel.
Otherwise, in effect, fetching the call from the queue must abort. I would
expect rather the latter, because the former would be quite difficult to
implement. The following example illustrates the case:

   protected Event is
      procedure Signal;
      entry Wait;
   private
      Signaled : Boolean := False;
   end Event;

   protected body Event is
      procedure Signal is
      begin
         Signaled := True;
      end Signal;
      entry Wait when Signaled is
      begin
         Signaled := False;
      end;
   end Event;
   
   task PID is
      entry Call;
   end PID;

   task body PID is
   begin
      accept Call do Event.Wait; end;
   end PID;

begin
  select
     PID.Call;  -- Blocked in the rendezvous
  then abort
     delay 2.0;
     Event.Signal; -- Releases the rendezvous after 2s
  end select;

If abort to happen after *completion* of the rendezvous then the above
shall not deadlock. (I checked this under GNAT/Windows, it deadlocks
there.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de