some remarks and requests for confirmation on tasks and protected objects

[Mehdi Saada <00120260a@gmail.com>]

The same tutorial says, different names for the same overloaded entry, with different profils are seen as distinct entries… What does that mean exactly ? They still have the same queue/list of tasks waiting at the gate, right ? Seems logical, but I ask for confirmation.

> loop
>	select
>		when CONDITION1
>			accept	SERVICE₁ (…) do
>			end service₁ ;
>	or
>		when condition₂	
>			accept service2 (…) do
>			end Service2 ;
>	or
>		delay Période ;
>	end select ;
> end loop ;
It is then impossible to make the server terminate other than through an external termination.
Is it still the case in Ada2012 ? Even I can tell you could well want a task to took for termination (see that all other tasks of the same master are terminated are aborted, and that the master has run out of statements to execute) at each iteration, during 2 seconds, and if things are still running, iterate again. Delay alternative and terminate alternative still exclude each other… Is there another way to do the same ?

> if a server task is aborted, all calling tasks being served  « tasking error ».
=> Wouldn’t it have been possible to have more… specific exceptions when it comes to tasking ? Like « CALL_ON_ABORTED_OR_TERMINATED_TASK_ERROR ».

=> for protected objects, what does the compiler knows what is « input/ouput », to forbid them in entries/protected subprograms ? How does it differenciate such instructions (potentially blocking) from other, since they are implemented through predefined libraries ?

=> About requeue : wouldn’t that be useful to be able to ditch at least in mode parameters ?

About the syntax for entry family index : 
> entry_index_specification ::= for defining_identifier in discrete_subtype_definition
or : entry REQUEST (for P in PRIORITY) (formal_parameters) when Condition(P) is
Hum… what’s that ? Why not using normal subprogram parameters syntax, instead of something that looks like loop index specification, since something like that

procedure MAIN is

   type SPEED is (FAST, MEDIUM, SLOW, SNAIL);

   protected Selector is
      entry Answer_Query(SPEED)(Counter : INTEGER);
   end Selector;

   protected body selector is
      entry Answer_Query(for F in FAST..MEDIUM)(Counter : INTEGER) when TRUE is
      begin
         Put("FAST Query made"); Put(Counter, 3);
      end;
      entry Answer_Query(for F in SLOW..SNAIL)(Counter : INTEGER) when TRUE is
      begin
         Put("MEDIUM Query made"); Put(Counter, 3);
      end;
   end Selector;

is not allowed anyway ? It could, if those intervals war made to be static, or if the end of the end of the first and first of second interval, coincide.

About impossibility to give different discriminants to tasks or protected type objects :
I thought about that before… The problem is, discriminants can be given for limited records at initialization, which LOOKS like an affectation, from the syntactic POV at least. But tasks are even more limited than that, you can’t «:= » them at all.
What about using the same syntax as with entry index specification :
task type Selector is
   entry Answer_Query(SPEED)(Counter : INTEGER);
end Selector;
TASK_ARRAY: array (1..8) of SELECTOR(for P in 1..8, ANY_FUNCTION(P)) ;
(I saw there are existing solutions, proposed by Barnes, but not as clean as that.