Re: Basic question about select

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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