Re: Asynchronous entry call proposal

[billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,)]

From article <124000037@inmet>, by stt@inmet:
> Here is the proposed new selective wait construct:
> 
> select
>    select_alternative
> { or 
>     select_alternative}
> and
>    sequence_of_statements
> end select;
> 
> The semantics of this construct are that normal processing is performed 
> on the select alternative guards to determine which should be "open."  
> Selection of one such open alternative takes place immediately if a 
> rendezvous is possible, or if a delay alternative of less than or equal 
> to zero seconds is open.  Otherwise, the sequence_of_statements begin 
> execution.  If the sequence_of_statements completes execution,
> then the select alternatives are closed.

    So far, what we have is precisely identical to the existing construct:

      select
         select_alternative
    { or 
         select_alternative }
    [ else
         sequence_of_statements ]
      end select;
   
> If prior to completion of the sequence_of_statements and outside of
> any nested rendezvous (either accept or entry call), a delay alternative 
> has expired, or an open accept alternative has a caller, then the 
> sequence_of_statements is abandoned, and an asynchronous transfer
> of control takes place to the appropriate open select alternative.
> This abandonment takes place no later than the next synchronization
> point, but it is the intent that any ongoing computation 
> (outside of a rendezvous) be preempted.  [...]  Example of use:
>
>     select  -- Perform time-limited calculation
> 	delay 5.0;
> 	Put_Line("Calculation does not converge");
>     and
> 	-- This calculation should finish in 5.0 seconds
>         -- if not, it is assumed to diverge
>         Horribly_Complicated_Recursive_Function(X, Y);
>     end select;

   This can be accomplished now by wrapping the function
   up in a task, activating it, delaying 5.0, and then 
   killing it off if it hasn't completed...

   > It was felt by most of the participants of [IWRT2] that
   > this approach was unacceptably expensive and inadequately
   > controllable.  

   But this will essentially have to be done anyway; it seems
   that this proposal would simply move the abort of the 
   sequence_of_statements "behind the scenes".  What improvement
   is being made which could not be applied more directly to simply 
   making the existing abort statement deliver better performance?


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

   P.S. I also didn't see any discussion of how the proposed
        "abortable else" would interact with the existing,
        non-abortable else section...  what if the programmer
        supplied both?  Or are you making them mutually exclusive?