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!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: How to tell whether program finalization can be suppressed Date: Sat, 02 Dec 2017 09:48:05 +0000 Organization: A noiseless patient Spider Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="0a0a02586a45d23e74b238e4b14633d7"; logging-data="420"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18tf919zLTnY9Nzs2ucHUj8JlqI8pA3JpE=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (darwin) Cancel-Lock: sha1:ogFNEumoT5G3vo6MfQUCPiqnmKs= sha1:1+4LmWqNlxnMw5oLYMJe/pUADl4= Xref: reader02.eternal-september.org comp.lang.ada:49322 Date: 2017-12-02T09:48:05+00:00 List-Id: "Randy Brukardt" writes: > "Simon Wright" wrote in message > news:lyzi729lh2.fsf@pushface.org... > ... >> Amongst other things, I can test for specific restrictions, and I'm >> wondering whether No_Task_Termination would be appropriate for this? >> (I'm assuming that the environment task mustn't terminate, even if >> the main program exits; and in this RTS, exceptions can't be >> propagated). [...] > In an embedded system that is supposed to run forever, one would > expect that the main subprogram would never exit. If it did exit, the > system would shut itself off, which probably would lead to task > waiting and then library-level finalization. After that, one would try > to restart the system from scratch. I suppose someone could build a > system that did something else on such an exit (which always > represents a catostrophic failure), but it wouldn't be very Ada-like - > finalization would not get performed on objects that are expecting > that (potentially leaving things in unusual states). Such a system > would have to start-up making no assumptions at all, even the ones > that usually could be made at power-up -- which sounds painful. I think this was a red herring - sorry. The thinking was, this is a Ravenscar RTS; Ravenscar includes No_Task_Termination; the environment task is a task; therefore it's not allowed to terminate. In any case, ARM 10.2(25)[1] doesn't appear to say that the main program shouldn't exit, or that if it does the system should shut down. [as a side remark, I take it that 10.2(10)ff are such that the implementation is expected to behave 'as-if'?] But of course the main program in an embedded system won't exit. System termination in a drone running on a microcontroller with 1M flash and 192K RAM, with No_Exception_Propagation, will happen because of some exception resulting in a last-chance handler getting called. I take your point about things being left in unusual states. At present, the Certyflie[2] software resets the motors and leaves the aircraft to tumble to the ground (normal takeoff weight 27g: max 42g, so not very hazardous). The chance of restoring normal operation to the point where the drone can do a managed landing rather than just crashing is slender. [1] http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-10-2.html#p25 [2] https://github.com/AdaCore/Certyflie