Re: How to get Ada to ?cross the chasm??

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 18-05-11 11:10 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> Yes yes, but at run-time the program allocates space dynamically, as
>> needed, _in_ the buffers and queues, though usually not by the "new"
>> keyword but by some application-defined "allocate buffer block" or
>> "enqueue" operation. And these allocations can fail at run-time, at
>> least under overload conditions.
>
> I'm still kind of surprised to hear that.  I thought Ada programs (once
> running) were supposed to never fail,

"Not fail" = work according to the specifications.

Suppose the specification says: "If a packet is received when the 
received-packet-queue is full, the program shall discard the new packet 
and increment the lost-packet counter", you see how the program is 
expected to work if it cannot allocate space _in_ the queue at run time.

An alternative specification could say, instead: "If a packet is 
received when the received-packet-queue is full, the program shall make 
room in the queue for the new packet by discarding the oldest enqueued 
packet from the queue". And the program would implement that, instead.

A third possiblity is to specify: "The program shall start the reception 
of a new packet only when the received-packet-queue is not full". This 
pushes the problem back to the entity sending the packets; perhaps the 
HW will lose any packets sent when the program is not trying to receive 
them, or perhaps there is flow-control on the link, and the sending 
entity is blocked (which may lead to an overflow of the transmission 
queues on the sending side).

> which means no dynamic anything,
> just a few allocations that might fail during startup, and then run with
> those resources and only those resources.

My point was about the meaning of "dynamic". People often think that 
"dynamic allocation" is only allocation from the system heap. But that 
is a surface distinction, because application-defined buffers and queues 
are also subject to run-time (and therefore "dynamic") allocation and 
release of space. The deeper question is if those allocations are 
certain to succeed (which could be ensured by some known or imposed 
limits on the input and output rates etc.) or may fail, and of course a 
failed allocation should not make the program fail to obey its 
specifications.

On the system level, the conditions (typically abnormal input rates) 
under which the dynamic allocations may fail should be understood and 
suitable recovery actions defined in the program specifications.

One problem with dynamic allocations from the system heap is that the 
conditions for failure (heap exhaustion) are global, depending on all 
uses of the heap, which makes it hard to specify how the program should 
handle a particular allocation failure.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .