[Development] QtCore missing check for memory allocation

[Konstantin Ritt]

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>:

> 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
> _______________________________________________
> 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>