Re: Finalization of library level tasks

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

On 27/04/2018 00:25, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:pbs4km$doq$1@gioia.aioe.org...
>> On 26/04/2018 01:46, Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:pavqa6$1qdj$1@gioia.aioe.org...
>>> ...
>>>> Yes. The problem is the order of finalization. For some unclear reason
>>>> the
>>>> task's access type is attempted before the object that contains that
>>>> access type because they are in the same scope.
>>>
>>> It's not unclear - tasks have to terminate before objects are finalized
>>> so
>>> that the tasks aren't trying to use finalized objects. If the object is a
>>> protected object, that could be a really bad deal (remember that
>>> finalizing
>>> a protected object raises tasking error in any queued task and prevents
>>> future calls).
>>
>> It is all objects, not just ones containing the task. You could have:
>>
>>     package A is
>>        task type Foo ...
>>        X : Foo;
>>     end A;
>>
>>     package A.B is
>>        type Bar is new Ada.Finalization.Controlled ...
>>        Y : Bar;
>>     end A.B;
>>
>> Even so, finalization of Y will await termination of X!
> 
> It has to. There is no way for the compiler to know that there is no way for
> X to access Y.
> 
>> The deadlock in the RM is constructed to prevent any possible way to break
>> it.
> 
> Correct, and that is by design. An unbreakable premise of Ada is that
> finalization of objects will always be done no matter what happens. That's
> why subpools have a finalization mechanism, Unchecked_Deallocation does
> finalization, assignment does finalization, ad nauseum. The designer of an
> Ada library (ADT) can always be assured that their last wishes will be
> executed regardless of what horrors the client tries to invent. This is a
> critical property for reusability.

It is not reusable when the code depends on whether the object is 
declared at the library level or not. It is not reusable when pointers 
are unavoidable. It is not reusable when the "standard" task termination 
method is not usable and must be always replaced with some kludge to be 
reinvented each time new.

>> There are dozens ways to fix the mess but there seems no interest at all.
> 
> Correction: there are dozens of ways to make a worse mess. There is no way
> to "fix" the issue, because any change to the rules just breaks in some
> other case. Or completely destroys the ability of ADTs to assume that
> finalization happens.

Nothing will be broken by adding a Boolean attribute T'Completion_Awaited.

Nothing will be broken by fixing the finalization model that does not 
distinguish finalization of the class from finalization of the 
type-specific object.

You *can* finalize the class of the object containing the task with the 
task component still running:

    type Container_Type is .. tagged ...
       T : Task_Type;

The order of finalization must be:

    Finalize Container_Type'Class;
    Stop T;                  -- Existing order
    Finalize Container_Type;
    Finalize T;

Note that Ada 95 type system wisely distinguished Container_Type'Class 
and Container_Type, while finalization inconsistently ignores the 
difference.

Nothing will be broken by adding user-controlled aspect to access type 
to kill any bookkeeping, any hidden lists, any dependencies.

[...]

> One of the advantages of the parallelism model in Ada 2020 is that you don't
> have to write explicit tasks so you don't have to deal with termination of
> them.

I don't see how this will help with designing active objects, writing 
servers for I/O protocols, handling pools of worker tasks.

If ARG wants get rid of explicit tasks it should seriously revise the 
type system. The task type must be an interface to derive from.

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