[Development] QtCore missing check for memory allocation

Konstantin Ritt ritt.ks at gmail.com
Wed Feb 25 22:17:39 CET 2015

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
Such a "centralized" memory allocation routines also could be very useful
in debugging or memory consumption monitoring.



2015-02-26 0:29 GMT+04:00 Marc Mutz <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,
> 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
> _______________________________________________
> Development mailing list
> 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/c11fdeda/attachment.html>

More information about the Development mailing list