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!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Fri, 11 May 2018 12:16:34 +0300 Organization: Tidorum Ltd Message-ID: References: <87k1sg2qux.fsf@nightsong.com> <87h8njmk4r.fsf@nightsong.com> <87po27fbv9.fsf@nightsong.com> <87in7x62vw.fsf@nightsong.com> <878t8szdtk.fsf@nightsong.com> <877eoa4noz.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net xrKc+QFKNlY14gpmxW6AIgZ6MYuU7Iehg2ZVZMov9AsIo94yQ6 Cancel-Lock: sha1:s9tDF8gh+QiWyWIanZFHfBsznl0= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <877eoa4noz.fsf@nightsong.com> Xref: reader02.eternal-september.org comp.lang.ada:52258 Date: 2018-05-11T12:16:34+03:00 List-Id: On 18-05-11 11:10 , Paul Rubin wrote: > Niklas Holsti 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 . @ .