On 29 Oct 2021, at 18:27, Karsten Pedersen wrote:
> 
> (2) Very happy to. Though do I need to look up at how FLTK deals with operator new() throwing exceptions on OOM situations.

Others are coming in with actually useful feedback, but I’ll just pick this up: “operator new() throwing exceptions on OOM situations”

Question: Have you ever seen that happen?

I have, but never on a modern desktop system. The memory allocators in all the “main” OS these days are, by design, *very* optimistic in their allocation strategy and pretty much never fail to allocate memory for a “small” request, and they depend on the MMU to sort that out when the allocation is actually needed and referenced. The consequence of that is that calls to new or malloc or etc. basically never fail.
A nasty side effect of that if you do seriously go OOM and the allocation can not be honoured by the MMU at point of use, you can get tricky (and hard to debug) faults “elsewhere” in the program at runtime.

A few years back, a colleague hit basically this issue, and we all stared at it for days before we figured out what was going on. Oddly, “the same” code running on vxWorks-5.something-ancient did OOM at the point the new was made, because it’s allocator was not optimistic and was mapping actual RAM at the point it was called... If we’d tried that first we’d have spotted it sooner!







-- 
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/A9966A42-EF73-4CB1-9ADE-5941CB4D53ED%40gmail.com.