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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.58.199.170 with SMTP id jl10mr8957456vec.1.1397151362131; Thu, 10 Apr 2014 10:36:02 -0700 (PDT) X-Received: by 10.50.79.133 with SMTP id j5mr361639igx.7.1397151361817; Thu, 10 Apr 2014 10:36:01 -0700 (PDT) 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!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!m5no568713qaj.1!news-out.google.com!gi6ni272igc.0!nntp.google.com!ur14no5790865igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 10 Apr 2014 10:36:01 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=KSa2aQoAAACOxnC0usBJYX8NE3x3a1Xq NNTP-Posting-Host: 66.126.103.122 References: <594ec168-808b-4b4e-96ff-5eb569e52413@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <827fab32-89b4-4dbd-a074-6cd86e6195f0@googlegroups.com> Subject: Re: Asynchronous Transfer of Control From: Adam Beneschan Injection-Date: Thu, 10 Apr 2014 17:36:01 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 2466 X-Received-Body-CRC: 4018564960 Xref: news.eternal-september.org comp.lang.ada:19223 Date: 2014-04-10T10:36:01-07:00 List-Id: On Thursday, April 10, 2014 8:15:53 AM UTC-7, I wrote: > I/O operations like Get_Line aren't abort completion points. It seems re= asonable that an implementation *should* provide for an I/O operation to be= aborted if it could be forced to wait (e.g. input from the console, waitin= g for a socket connect, etc.). But the RM doesn't require it. One thing I didn't notice is that 9.8(15) says: "If the execution of a construct is aborted at a time when the execution is= blocked, other than for an entry call, at a point that is outside the exec= ution of an abort-deferred operation, then the execution of the construct c= ompletes immediately." I'm still not convinced that applies here. In an informal sense, a task th= at is waiting for the user to press a key could be said to be "blocked". H= owever, 9(10) discusses the different states a task goes through: "A task i= s initially inactive; upon activation, and prior to its termination it is e= ither blocked (as part of some task interaction) or ready to run." A task = that is stopped because it's waiting for user input is not stopped "as part= of some task interaction", so I don't think it's formally "blocked". -- Adam