Re: thread interruption points
On 21.02.15 17.50, ?? Tiib wrote:
Well, pretty much any existing C++ application will never recover from
an allocation error in a reasonably way.
What you are saying is that majority of applications have never been
stress-tested. Pretty much all C++ (and C) applications that have been
stress-tested by semi-proficient quality engineer will recover
reasonably.
I have never seen C++ code that is really safe with respect to memory
exceptions. Sometimes it might work, but as soon as there is even a
single allocation during stack unwinding it is likely to run into the
same problem again. The logging functionality usually already breaks
with this rule.
And as soon as a function with throw() is in the call stack that does
not handle the exception at all places, std::abort will terminate the
application. From the applications point of view this is undefined
behavior. From the language point of view of course not.
Difficulties might be only when underlying platform is
configured to behave in brain-damaged way like with that "Linux OOM
Killer".
:-)
Simply because almost everything requires some successful memory
allocations. Even if only for allocation of the std::string with
the error message.
So the application can be on worst case in situation where it can
do nothing from that "almost everything". That appears to be plenty
for to behave reasonably.
But how to continue in a useful way? When the expected functionality is
unsustainable without some free memory the application likely will no
longer work. Unless the stack unwinding happens to free a reasonable
amount of memory, everything else is just luck.
The C++ language is not well designed to provide guaranteed behavior
with respect to memory demand. It is simply not known how much memory is
required to operate properly. Software producers test the application
and add some safety factor for the system requirements.
There have been languages that do suffer from this. I remember OCCAM
that computes the required stack usage of any thread at compile time.
But many algorithms cannot be used in such an environment.
Marcel