_set_new_handler vs. set_new_handler

[Marcel Lanz]

On Thu, Aug 25, 2005 at 07:09:40PM +0200, Lindner Bernhard wrote:
> This isn't exactly what I want to do. This solution of course is an
> improvement compared to the default out-of-memory handler (which simply
> does nothing to recover the situation). But the original method I
> described is much better because the user is requested using a fall back
> dialog and even in the case of a very big lack of memory, the user can
> continue the application by closing any number of other programs to free
> enough memory. 
> 
> The above solution only works if the panic memory is as big as the lack
> of memory (which is not very likely because the panic memory may not be
> very big if I want to prevent my application from wasting resources).

it doesn't waste memory, it frees preallocated memory at certain steps,
and the user of "new" will get the memory it needs after the
preallocated memory is freed up in the handler. I use it in an embedded
environment, where I can't "pop up" a window, but log the event an track
unexpected memory usage on the device.

as a general rule, memory should not exeed; and if so, we log it instead
of abort()

decide which "application" to kill on the event is not easy without
user intervention.

so I think, if you can ask a user to kill apps, you have an OS with
paging memory system, and a big disk with a swap partition/file. these
days, a 5 GB swap partition is easy to have.

otherwise I'd mark low-priority processes and kill them on demand. I
prefer to have a log about such events and then think about memory allocation
pattern of the application.

marcel