[cap-talk] Memory allocation in embedded systems

[David Hopwood]

David Hopwood wrote:
> It's not always necessary to prove that an allocation will not fail, as long
> as the behaviour if it does fail is reasonable and meets the specification.
> In the printer app, there is only one point at which an allocation attempt
> may fail, and that will cause a print job to be rejected, with an error
> reported to the client that tried to submit it.

Now that I check more thoroughly, there are two places for memory, and one for
disk space. The other memory case will report that an implementation limit in a
configuration file has been exceeded. The disk case will also reject the print job
(and the user will previously have received a warning that disk space is low).
Print jobs are stored on a separate partition, so that running out of space on
that partition does not affect the OS or the application, in much the same way
as using separate memory pools.


I also intended to mention that it is often possible to avoid allocation failures
by careful design of the user interface: the user can be prevented from starting
an operation that would lead to an allocation failure, rather than reporting the
error when it occurs part-way through the operation.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>