On Nov 10, 2011, at 18:03 , Don Quixote de la Mancha wrote: > I don't have a problem with the system killing runaway processes. > What I have a problem with is that calloc() NEVER returns NULL. If it > ever did, I would have plenty of opportunity to deallocate ALL of the > memory I just allocated, and stop attempting to allocate any more. > > Instead of ever receiving an allocation failure, my process is just killed. > > My process isn't killed by a UNIX signal. If it were I could use a > signal handler to free up all that memory. > > calloc() and malloc() are documented to return NULL when there isn't > enough memory to satisfy the user's request. Their implementation is > simply broken if they don't do that.
Your argument is weak because you've made a whole series of unsubstantiated claims in this thread. You haven't demonstrated that calloc "NEVER returns NULL". You've only demonstrated that your app is killed in the particular usage scenario you described. You haven't demonstrated that your app is killed because calloc failed. It may well have been that the calloc calls all succeeded, thus putting your app in a state where it *appeared* to be engaged in runaway memory allocation, and *that's* the reason it was killed. You haven't (IIRC) demonstrated that your app is not receiving memory warnings. It was pointed out to you that you seemed to be allocating memory in a loop that did not return to the main event loop (from where the warnings would be dispatched), but you didn't respond on this issue (again, IIRC). In this sense, it looks like your problem isn't anything to do with memory allocation failure, but rather your insistence on a code pattern that violates iOS's good citizenship rules. You probably have good reason to request (via bugreporter) a mechanism that would give apps a clue as to the how much memory they should limit themselves to asking for when they know they need "a lot" of memory. However, I'd speculate that Apple's not likely to make this design pattern easier, because it invites the bad-citizenship approach to iOS app design. You may need to find a different approach to your app design that allocates memory incrementally at the point where it's actually needed, rather than trying to preallocate anything. That might be much harder, and might make the computational optimization harder, but you'd have a better app (e.g. perhaps one where the user didn't need to configure the grid size -- I think you said earlier the ideal is an infinite board, not a finite one). Indeed, an innovative memory management design may even produce a more effective computational optimization. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
