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!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Finalization of library level tasks Date: Thu, 26 Apr 2018 17:25:50 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Thu, 26 Apr 2018 22:25:51 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="20698"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:51734 Date: 2018-04-26T17:25:50-05:00 List-Id: "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. > 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. When we ran into the problem in the Claw design, I spent a lot of time trying to come up with a fix. I couldn't find anything that didn't have worse problems in some cases. I believe other ARG members did the same thing; the environment task solution seemed to be the best workaround (it works great in Claw, presuming of course that the compiler implements it correctly). Claw, for instance, uses a number of locks. We had problems with compilers finalizing those locks before awaiting tasks, meaning that the tasks got Program_Error for no expected reason. (And one compiler that will remain nameless just crashed if you called such a lock; there's an ACATS test for that, too, these days.) The critical thing from an Ada perspective is that the rules are well-defined and don't change from implementation-to-implementation. Then it is always possible to find a solution (not necessarily an easy one). Task termination is rarely considered in Ada books, yet it is one of the hardest things to accomplish. I don't have any termination technique at all in the spam filter, because I couldn't think of anything that would actually work. Luckily, you can just kill the process from Windows in the few cases where you need to shut the thing down. 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. Randy.