From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Finalization of library level tasks Date: Fri, 27 Apr 2018 09:37:44 +0200 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 X-Notice: Filtered by postfilter v. 0.8.3 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:51742 Date: 2018-04-27T09:37:44+02:00 List-Id: On 27/04/2018 00:25, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:pbs4km$doq$1@gioia.aioe.org... >> On 26/04/2018 01:46, Randy Brukardt wrote: >>> "Dmitry A. Kazakov" 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