[Development] QtCore missing check for memory allocation

[Marc Mutz]

On Wednesday 25 February 2015 16:30:56 Giuseppe D'Angelo wrote:
> And on the other hand, this assumption of having infinite memory has 
> held for a while

Only in the niche that Qt exists in. Now, the question is whether Qt does not 
play a role in systems that handle oom gracefully because Qt doesn't handle 
them gacefully or whether it doesn't play a role in those systems because 
there are no such systems. 

But I'm sure there are embedded systems that fall in between the desktop model 
of inifinite VM space and hard-realtime systems that allow no dynamic memory 
allocations after program initialisation. For such systems, recovering from 
oom is actually a plausible alternative. Relying on the oom killer in a soft 
realtime application is asking for trouble. It can literally take an hour for 
the system to recover. I just experienced a 50min thrashing when I dared to 
start up a 4GB VM without waiting for qtcreator to fully quit. The oom killer 
killed qt-creator, but it _did_ take 50mins.

As Ossi said, overcommitting is likely turned off in those systems. BTW, IIRC, 
you also get nullptr mallocs (without thrashing swap first when you run into 
user-defined ulimits.

If Qt wants to be(come) relevant to that part of the embedded space (or that 
part of server space that still uses ulimit), we better stop acting like 
there's only infinite memory.

> -- why should now people have a slower library because 
> of all those checks?

Q_CHECK_PTR does not necessarily make the library slower. It only needs to be 
applied to malloc/calloc and nothrow operator new, because ordinary new 
already throws. We can port such code to normal operator new instead.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions