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