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!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.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: Fri, 27 Apr 2018 16:08:50 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Fri, 27 Apr 2018 21:08:52 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="14637"; 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:51751 Date: 2018-04-27T16:08:50-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:pbuk07$9mf$1@gioia.aioe.org... ... > It is not reusable when the code depends on whether the object is declared > at the library level or not. That only happens if you write broken code in the first place: tasks should never be embedded in objects. It simply doesn't work (Ichbiah got that wrong). When you do so, termination is a problem, but so is avoiding deadlocks, race conditions, and the like. The entire nesting model of tasks in Ada is huge overkill and should never have happened - it's a huge amount of complexity for a value approaching zero. (Note that the first thing Ravenscar discards is the nesting model.) >>> 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. I've been told that would lead people to writing code which depends on race conditions. I'm not enough of an expert on tasking to try to disagree with people that are. > Nothing will be broken by fixing the finalization model that does not > distinguish finalization of the class from finalization of the > type-specific object. A class is purely a static construct (just like privacy), while finalization is a purely dynamic construct. There's nothing to "distinguish" -- at runtime, all objects have a specific type. Finalization of a "class" can do nothing, as there is nothing dynamically to do with classes. ... > Nothing will be broken by adding user-controlled aspect to access type to > kill any bookkeeping, any hidden lists, any dependencies. Of course, the invariant that finalization always happens would be broken. That's a dead body issue with me, as it would destroy the ability to write reusable libraries. Note that as with memory allocation, a well-designed reusable library needs to be agnostic as to how clients use it in tasks. It should work properly when used sequentially, with multiple tasks, with parallel blocks/loops, and anything yet to be invented. That means nothing active should be in the library anymore than that the library should be allocating any memory. ... > I don't see how this will help with designing active objects, writing > servers for I/O protocols, handling pools of worker tasks. IMHO, active objects are evil. Use something like Parafin for pools for worker tasks (or just a parallel loop with the task checking turned off). "terminate" works fine for most servers, that's what it was designed for. And both pools and servers are always going to be at library level, so the workarounds can be used if "terminate" doesn't work. Randy.