Re: Finalization of library level tasks

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

On 2018-04-15 16:54, Jeffrey R. Carter wrote:
> On 04/15/2018 04:12 PM, Dmitry A. Kazakov wrote:
>>
>> The problem is that Finalize is called when the object is declared in 
>> a nested scope:
>>
>>    procedure Main is
>>       Data : X;
>>    begin
>>       Data.Worker := new Worker_Type;
>>    end Main; -- Finalize is called (and terminates the task)
>>
>> This does not work:
>>
>>    package Library_Level is
>>       Data : X;
>>    end Library_Level;
>>
>>    with Library_Level;
>>    procedure Main is
>>    begin
>>       Library_Level.Data.Worker := new Worker_Type;
>>    end Main; -- Finalize is not called (presumably waiting for the task)
> 
> A task declared by an allocator (usually) depends on the thing that the 
> access type is declared in; here, that's a library-level pkg.
> 
> An object declaration such as Data goes out of scope when the thing that 
> it's declared in goes away. In a procedure, the procedure can end and 
> Data can be finalized, even though Data.Worker.all is still running. You 
> might, for example, copy Data.Worker to another variable of the access 
> type that will exist after the procedure call ends. Or you may want the 
> task to exist and run with no way to refer to it; tasks in worker pools 
> often work this way.

That would not work because the task actually has an access discriminant 
pointing the container type.

> When Data is declared in a library-level pkg, it's finalized when the 
> pkg goes out of scope, which doesn't happen until all library-level 
> tasks have terminated. Since Data.Worker has a library-level access 
> type, Data.Worker.all is a library-level task.

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. The effect is that task 
termination is requested prematurely. I hoped that there is some trick, 
e.g. fooling the accessibility rules of the access type, some sort of 
Unchecked_Allocation. Ada 83 had pragma Controlled to require the 
compiler to keep its hands off, alas, it was removed.

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