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.m...@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.m...@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development