2008/8/22 Chris Wright <[EMAIL PROTECTED]>: > 2008/8/22 Tilman Baumann <[EMAIL PROTECTED]>: >> Pardon. >> I don't care for the warm and fuzzy feeling you get by having malloc >> fail on you. >> >> It does not give you a bit more system stability! The one app >> receiving malloc errors is just not app of many. They all have a >> problem then. >> Imagine, the browser catches a failed malloc, because some other >> stupid app has eaten almost all ram. >> What is the benefit of telling the browser about low mem? It could >> only safe itself from crashing. Well done. > > Imagine that malloc() returns null rather than overcommitting. > Most affected apps will receive a SIGSEGV when malloc returns null > because there's no error handling for that situation. > Some will notice that malloc() returned null and either forgo some > optional stuff or abort a single operation or simply just shut down > gracefully.
On the other hand, let's say your process allocates some memory and doesn't use it for a while. In the meantime, some memory is freed. This doesn't help if malloc() returned null, but it does help if the kernel overcommitted memory instead. I don't think that's as useful. But you could instead define a malloc: void* _malloc(size_t length) { void* pointer = malloc(length); if (!mlock(pointer, length)) return null; // or abort return pointer; } _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community