Re: Asynchronous Transfer of Control

[Adam Beneschan <adambeneschan@gmail.com>]

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 reasonable 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, waiting 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 execution of an abort-deferred operation, then the execution of the construct completes immediately."

I'm still not convinced that applies here.  In an informal sense, a task that is waiting for the user to press a key could be said to be "blocked".  However, 9(10) discusses the different states a task goes through: "A task is initially inactive; upon activation, and prior to its termination it is either 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