Re: some remarks and requests for confirmation on tasks and protected objects

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

On 06/03/2018 12:43, Mehdi Saada wrote:
> 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 

It is up to the implementation. I can imagine one with only one queue 
for all entries indexed by topics appearing in the guard expressions.

? 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.

That's right, it is a language bug. However the terminate alternative is 
useless anyway because of another bug. Tasks practically cannot be 
components and Unchecked_Deallocation of a task is broken. So the 
pattern *always* is:

    loop
       select
       ...
       or accept Quit;
          exit;
       ...
       end select;
    end loop;

In the Finalize:

    procedure Finalize (X : Enclosing_Object) is
    begin
       ...
       if X.Worker /= null then
          X.Worker.Quit; -- Ask to terminate
          while not X.Worker'Terminated loop -- Wait it to terminate
             delay 0.01;
          end loop;
          Free (X.Worker); -- Now we can free it
       end if;
       ...
    end Finalize;

>> 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 ».

You don't have a context for that. A natural solution is a rendezvous 
with the master when a child task crashes. Then on its behalf a 
rendezvous is engaged and the master can accept it:

    select
       accept T'Child_Fault
              (  Error : Exception_Occurrence;
                 Child : Task_ID
              )  do
          Put_Line ("My child failed me: " &
                 Exception_Information (Error));
       end T'Child_Fault;

The rendezvous follows the "chain of command" up to the environment task.

> => 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 ?

It is the programmer's responsibility. There are other things which are 
legal but should not be done there ether, e.g. loops, heap allocation etc.

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

It certainly would, but it would require special rules of parameter 
matching.

> 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 ?

[...]

> 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.

I think this is related to inability to change entry call parameters. 
That is the only practical use case for families. It would be actually 
enough to allow "hidden" entry parameters invisible and defaulted to the 
caller but visible to the protected object or task who can modify them 
before re-queuing.

> 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.

There should be constructors, that solves this and many other issues. 
Limited returns and aggregates must be removed from the language. Yes, 
all existing code that uses them must be rewritten.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de