Re: Asynchronous Transfer of Control

[Adam Beneschan <adambeneschan@gmail.com>]

On Thursday, April 10, 2014 3:41:15 AM UTC-7, AdaMagica wrote:
> This piece of code is very similar to RM 9.7.4(10-13).
> 
> It seems that GNT GPL 2013 on Windows does ot work correctly.
> 
> with Ada.Text_IO;
> use  Ada.Text_IO;
> with Ada.Calendar;
> use  Ada.Calendar;
> 
> procedure Run_It is
> 
>   Line: String (1 .. 10);
>   Last: Natural;
>   Now : constant Time := Clock;
> begin
>   select
>     delay 10.0;
>     Put_Line ("aborted   " & Integer'Image (last) & Duration'Image (Clock - Now));
>   then abort
>     Put (" > ");
>     Get_Line (Line, Last); 
>     Put_Line ("terminated" & Integer'Image (last) & Duration'Image (Clock - Now));
>   end select;
> end Run_It;
> 
> This is the result if I only press <return> after the delay has expired:
> 
> C:\...\Ada-Kode\run_it
> 
> terminated 0 26.688941821
> aborted    0 26.689382659
> 
> [2014-04-10 12:24:42] process terminated successfully (elapsed time: 26.92s)
> 
> I.e. the abortable_part is not aborted.
> 
> Am I missing something? Or is this expected behaviour on Windows?

The RM says that when the abortable_part is aborted, it doesn't actually have to stop executing until the next abort completion point.  The abort completion points are defined in 9.8(16-19).  The abortable_part *could* be terminated at other points (as long as they're not inside abort-deferred operations, see 9.8(6-11)), but it's up to the implementation.

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.
  
Based on that, I think the examples in 9.7.4(10-13) are flawed.  While those kinds of examples may be the intended use of the asynchronous_select, they don't necessarily work, and the RM should probably make it clear that the effect is implementation-dependent.  In particular, the comment in the first example, "-- This will be abandoned upon terminal interrupt", appears to be making an assertion that is not necessarily true.  I'm planning on sending something to Ada-Comment about this.  (Don't know why I didn't notice this before.)  In the second example, we don't know whether Horribly_Complicated_Recursive_Function contains any abort completion points or not.  If it's a mathematical calculation, chances are that it doesn't; however, adding "delay 0.0;" statements at key places in the calculation would add abort compeltion points, and hopefully this statement would be implemented in a way so that it isn't a severe drag on efficiency.  (There's also Ada.Dispatching.Yield, which the RM says is a "task dispatching point", but it's not clear to me whether all task dispatching points are also abort completion points--seems like they should be, but I'd have to check the RM further.)

My understanding is that Windows makes it more difficult than, say, Unix/Linux to forcibly interrupt a thread, without that thread's cooperation.  That is, if I recall correctly, the thread to be interrupted has to use different versions of I/O API calls, and/or special API routines, that enable the operation to be interrupted.  I think that system designers have come to believe that allowing threads to be interrupted at any arbitrary point causes problems.  As I mentioned above, it may be a reasonable expectation that a keyboard input subprogram should allow for thread interruption, but others may have different opinions; anyway, it's not a requirement and GNAT apparently doesn't do it.

                                -- Adam