On Tue, Nov 8, 2011 at 11:46 PM, Greg Parker <[email protected]> wrote: > On Nov 8, 2011, at 10:56 PM, Don Quixote de la Mancha wrote: >> On Tue, Nov 8, 2011 at 10:49 PM, Kyle Sluder <[email protected]> wrote: > No, the reason is that most end-users do not want to pay Space Shuttle prices > (high) for Space Shuttle capability and flexibility (low). > > Note that Shuttle missions carried ordinary laptops running ordinary > operating systems to do the science work other than flying the spacecraft. > The scientists couldn't afford Shuttle-grade development costs nor > Shuttle-grade development schedules.
One really doesn't have to pay Space Program prices for decent software. Improved development methodologies can actually save both the developer and end-user money. Xcode has a built in unit testing framework. How many of us are actually using it? On StackExchange a while back some coder bemoaned the fact that his employer specifically forbid him to spend time writing unit tests! The Code Red worm replaced damn near every Windows Internet Information Server website with a plain white web page that said simply "Hacked by Chinese". It was estimated at the time that that one worm cost the world economy ten billion dollars. A self-employed friend who ran Windows Server 2003 at the time prepared an online presentation for a potential client. When the client went to view my friend's presentation, he got just "hacked by Chinese". Would IIS really have had to cost as much as a Space Shuttle for Microsoft's coders not to have made IIS exploitable that way? While the iOS and Mac OS X do have a better security track record than Windows does, I'm quite certain that's because "The Scene" has been focussing on Windows due to its greater numbers. With Apple's increasing financial success, malware such as Mac Defender is starting to crop up. Apple's security update to fix the Mac Defender exploit was a gigabyte download - compressed! That suggests that whatever holes Apple plugged were all over creation. >> That's just it. I DON'T receive any memory warnings. As far as I can tell, >> neither does the system send my App a UNIX signal. > > Go back to Dave Zarzycki's message earlier in the thread. There are two > resources called "memory" that you can exhaust. > > Physical pages. If you use too many physical pages, then iOS will send you > memory warnings and, if you don't relinquish enough memory in response, kill > you. That would be great if I actually received any memory warnings. I don't. I had not yet implemented the memory warning delegate methods when I first experienced the iOS killing my App when I allocate too much memory, so implementing them was the very first thing I tried. There are two kinds of memory warning methods, one for your App Delegate, the other for each of your UIViewControllers. All of my view controllers now inherit from a common base class, with the memory warning being sent to the base class. Both of my methods set a global flag. Instead of calling calloc() directly I instead call a wrapper function that checks this flag, and returns NULL if it is set. Only after deleting ALL of the new allocations do a clear this flag. I wasn't sure that would actually work because I don't actually free memory in response to the memory warnings. I only prevent further allocations. It is when the next allocation fails that I free all that memory. However, I did set a breakpoint at both methods. That breakpoint was never hit. > Virtual address space. If you fill your virtual address space, then malloc > and mmap may fail and other frameworks may crash. The Simulator does the right thing: calloc I'm sure calls through to malloc, which itself calls mmap. mmap fails when I run out of virtual memory space. That can happen either because there is no more room in the backing store files, but not in my case as Mac OS X grows the backing store as needed. In my case I'm pretty sure I did run out of virtual address space. But then Mac OS X did the right thing, by having calloc return NULL. That enables my simulated App to unwind all those allocations to fail, then advise the user to try a smaller grid size. With both my App Warp Life, and the minimal test case that I attached to my bug report, the Simulator does the right thing while on an iOS device, the iOS just kills my process. I do not receive memory warnings, the process is killed before calloc returns anything at all, and I do not receive a UNIX signal. I would have expected the Cocoa Touch memory warnings to be implemented by UNIX signal handlers but that does not seem to be the case. If it were, I could write my own signal handler that would allow me to free up the memory. I don't have a problem with your assertion that my App should not allocate boatloads of memory. What I do have a problem with is that my App is terminated without it being given the opportunity to free any of the memory I have allocated. -- Don Quixote de la Mancha Dulcinea Technologies Corporation Software of Elegance and Beauty http://www.dulcineatech.com [email protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
