Re: How to tell whether program finalization can be suppressed

[Simon Wright <simon@pushface.org>]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Simon Wright" <simon@pushface.org> 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