Re: thread interruption points
On 21.02.15 22.41, Paavo Helde wrote:
Running out of memory is pretty fatal, but it's more complicated than
that. Some large image/data processing programs may often allocate memory
blocks of hundreds of MB or even gigabytes. Statistically such
allocations have a greater chance to trigger out-of-memory conditions
than small allocations. If such a large allocation fails, then there is
still plenty of room to allocate any error and logger messages, no
problem here.
Rather, the problems appear because there is usually some swap/pagefile
configured. The OS typically pushes other programs and parts of the same
program to the swap and the system starts heavily trashing. Typically the
programs are not well tested when running in swap and start failing in a
random fashion. Even if they are not failing, the computer is pretty much
> unusable anyway. Depending on the OS and running programs, a computer
> restart might be the best option to come out of the trashing mode. I am
You are right. I can confirm this. Win7 discards the disk cache on
suspend to disk. This is comparable to swapping after resume. About 1GB
of data is read with heavy disk activity in the first few minutes after
resume - probably in 4k blocks due to page faults. In this time the
system is almost unresponsive and random faults occur from time to time.
E.g. drivers that do no longer recognize there devices or program
windows can no longer rearrange their Z order (This can happen to any
window including simple explorer windows.). Of course, nothing bad
happens as long as you have only a few application windows open at
suspend and the cache is quite small. So the concept is well designed to
survive a feature presentation, no more no less. (What the hell came
over them when they decided to discard the cache.)
I once run into a similar problem on a Linux VM server too. I started
one VM too much and the memory got very low. It was impossible to get a
shell to suspend one of the VMs in a reasonable amount of time. So I
decided to prefer a hard reset.
starting to think that turning the pagefile off completely might be the
best approach.
Unfortunately you have to be careful here. Depending on the OS this
might have unwanted side effects. Some OS refuse overcommitment of
memory when there is absolutely no swap. Maybe some reliable operating
mode intended for cash terminals or something like that. This will
likely throw out of memory exceptions very soon when using ordinary
desktop applications.
Other OS simply ignore your configuration and create a temporary swap
file on the system volume in this case.
That's why throw specifications is a deprecated antifeature.
Is it?
And
functions with an empty throw clause should not call anything non-
trivial, if they do there is a large problem between the keyboard and
chair.
Well that's the old discussion whether to have checked exceptions or
not. Unfortunately when using generic functors or lambdas you have
almost no choice. You cannot reasonably use checked exceptions with
them, as it would require the throws declaration to be a type argument.
(Is this allowed at all?)
The memory is a global resource; if it is exhausted because some other
program tried to eat it all, then I think a good approach is to wait
silently in the OOM handler until the situation gets better, then retry
the allocation. Alternatively, if the program itself is the memory hog,
then it can probably release a lot of it by stack unwinding (in the
correct stack!), then report a failure.
I think it always depend on the individual case. And the basic question
is simply who pays to cover all this cases. Probably no-one.
Dynamic memory allocation can be handled relatively well in C++.
In the language: yes. In C++ libraries, well, it depends.
Stack
overflow is a different beast altogether, there are no standard
mechanisms for dealing with that and most program(mer)s just ignore the
problem and hope they get lucky.
Indeed.
Marcel