[Development] QtCore missing check for memory allocation

[Al-Khanji Louai]

How is that different from linking a custom implementation of operator new/operator delete and malloc/free into Qt?

These are embedded use-cases anyway, so you wouldn’t be using a stock Qt binary.  Implementing the above is well-documented, and in fact both C++11 and C++14 have improved the ways in which the new/delete can be overridden.

Just put your implementation in a static lib and pass it to the configure script as an additional library.

--Louai


Maybe a bit off-topic: can we introduce our own (probably customizable)  memory allocation API, something like Apple's CFAllocator [1], and move Qt internals to use it instead of malloc/realloc/free (and maybe instead of some new/delete-s, based on some policies)?
Then we could let the user to decide if he needs a OOM safety, i.e. with QAllocator::setDefaultAllocator(..)
Such a "centralized" memory allocation routines also could be very useful in debugging or memory consumption monitoring.

Regards,
Konstantin

[1] https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFAllocatorRef/

2015-02-26 0:29 GMT+04:00 Marc Mutz <marc.mutz at kdab.com<mailto:marc.mutz at kdab.com>>:
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<mailto:marc.mutz at kdab.com>> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com<http://www.kdab.com> || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150226/7ae65279/attachment.html>