Live data from Hacker News

Mobile Multitasking

daringfireball.net

61–68 of 68 posts

Re: Mobile Multitasking

#61

Earlier quoted context omitted.

It doesn't have the SPOD, but it does occasionally freeze with an app in an unusable state. The SPOD is only not there because they didn't add it, not because an unresponsive system is impossible with the iPhone OS.

SPOD doesn't mean an unresponsive system , just an unresponsive app so this a functional regression in iPhone if you can't switch to other apps while the frozen one recovers.

But sometimes it does mean an unresponsive system. All an application has to do is allocate a bunch of RAM (or spin the CPU on a number of threads >= cores) and the system slows to a crawl. It can't really kill those apps unless I ask it to, because work might be lost.

On iPhone, if apps save as they go, excessive usage can be solved with a kill -9 when I press the home button. Relaunching the app will take a few seconds and is transparent; I don't have to fight with the malfunctioning instance.

Re: Mobile Multitasking

#62
post #26

Moore's law seems to be in full effect for handsets. I think a lot of the innovation here is a stop gap measure before these handsets have virtual memory, making the complication behind multi tasking obsolete. On a side note, I seem to take heat every time I imply that phones will end up on par with PCs. The common theme I've been pushing is that most of the developments we've seen in PCs over the past decade will re…

I hope not. My iPad with 256MB of RAM and a relatively slow ARM processor feels snappier than my laptop with 2GB and a dual-core 64-bit Intel processor, partly due to the consistency: I never know, on the latter, whether an application will respond quickly (because it is active in memory), or slowly (because it isn't). If I could use iPhone OS's model on my laptop-- with more freedom due to the increased memory, but still omitting swap in favor of automatic saving/memory management-- I would.

though, who knows, maybe the declining cost of RAM will solve this problem for PCs, and eventually phones.

Re: Mobile Multitasking

#63
post #26

Moore's law seems to be in full effect for handsets. I think a lot of the innovation here is a stop gap measure before these handsets have virtual memory, making the complication behind multi tasking obsolete. On a side note, I seem to take heat every time I imply that phones will end up on par with PCs. The common theme I've been pushing is that most of the developments we've seen in PCs over the past decade will re…

It gets a little silly to talk about "phones" in this context. Making and receiving one-to-one voice communications is already just one of many features, and arguably already not the main feature.

And, on the iPad, not a feature at all. :)

Re: Mobile Multitasking

#64
It'll be interesting to see if Snow Leopard's NSPurgeableData and related stuff moves to iPhone OS. (I gather Google's phone OS have something similar).

That'd let developers have cached data that the OS knows it can blow away safely if memory gets low. The app then just regenerates the cache when necessary.

If iPhone OS could look around running processes for purgeable data, it could avoid or postpone killing apps outright. That would only be necessary if purging wasn't sufficient.

In fact, this seems a lot more useful on a swap-free phone than on OS X itself.

Re: Mobile Multitasking

#65

It'll be interesting to see if Snow Leopard's NSPurgeableData and related stuff moves to iPhone OS. (I gather Google's phone OS have something similar). That'd let developers have cached data that the OS knows it can blow away safely if memory gets low. The app then just regenerates the cache when necessary. If iPhone OS could look around running processes for purgeable data, it could avoid or postpone killing apps o…

> I gather Google's phone OS have something similar

Android apps are written in Java. So the standard approach for doing this is to use Java's weak & soft references which basically tell the GC that, "hey, I've used this memory but if you really need it back, you can have it!".

http://developer.android.com/reference/java/lang/ref/SoftRef...

Re: Mobile Multitasking

#66
post #61

Earlier quoted context omitted.

SPOD doesn't mean an unresponsive system , just an unresponsive app so this a functional regression in iPhone if you can't switch to other apps while the frozen one recovers.

But sometimes it does mean an unresponsive system. All an application has to do is allocate a bunch of RAM (or spin the CPU on a number of threads >= cores) and the system slows to a crawl. It can't really kill those apps unless I ask it to, because work might be lost. On iPhone, if apps save as they go, excessive usage can be solved with a kill -9 when I press the home button. Relaunching the app will take a few sec…

on osX (or any other OS), if apps save as they go, excessive usage can be solved with a kill -9 whenever the OS likes..

Re: Mobile Multitasking

#67
post #60
post #58

Earlier quoted context omitted.

Document Open certainly didn't prevent proprietary document nightmares. Lock-in is only an issue inasmuch as users don't demand a sane export. Pages documents could be a proprietary, patent-protected nightmare internally and it wouldn't matter to me: when I want the document out, I export it back to myself in a standard format. (Sure, it'd be nice to have a mass-export, but these things will come with time.) Automati…

Yes proprietary formats encourage lock-in too and open standard doc formats are better. But the 'export' that you mention requires a document open (or 'import') on the other end. I mostly agree with you on the rest.

And apps like Pages already have an import.

Re: Mobile Multitasking

#68
post #65

It'll be interesting to see if Snow Leopard's NSPurgeableData and related stuff moves to iPhone OS. (I gather Google's phone OS have something similar). That'd let developers have cached data that the OS knows it can blow away safely if memory gets low. The app then just regenerates the cache when necessary. If iPhone OS could look around running processes for purgeable data, it could avoid or postpone killing apps o…

> I gather Google's phone OS have something similar Android apps are written in Java. So the standard approach for doing this is to use Java's weak & soft references which basically tell the GC that, "hey, I've used this memory but if you really need it back, you can have it!". http://developer.android.com/reference/java/lang/ref/SoftRef...

Android also has the MemoryFile class, which can be set "purgeable".

"MemoryFile is a wrapper for the Linux ashmem driver. MemoryFiles are backed by shared memory, which can be optionally set to be purgeable. Purgeable files may have their contents reclaimed by the kernel in low memory conditions (only if allowPurging is set to true). After a file is purged, attempts to read or write the file will cause an IOException to be thrown."

Post reply on HN