ER: Ability to spawn helper processes on iOS

Originator:lebpierre
Number:rdar://9115604 Date Originated:10-Mar-2011 08:20 PM
Status:Closed Resolved:no
Product:iPhone/iPod touch Product Version:4.0
Classification:Enhancement Request Reproducible:always
 
On iOS devices, the jail prevents apps from fork()ing (and likely, execve()ing). It would be nice, however, if we could spawn helper processes that wouldn't even live longer than the app process does, so that operations that could potentially crash could be done inside such a spawned process, so that only that process would be brought down instead of the whole app.

The use case is the following: we have a media playback application. The user can bring his own media files, they do not come from us, we do not control them, and I don't know if you've worked in multimedia, but some of these media files floating around are nasty; not necessarily exploits, but they violate the file format in numerous ways, yet are somehow playable by some players out there, and they tend to crash our application.

While we of course strive to fix such crashers, meanwhile we want inconvenience to the customer to be reduced as much as possible. It's not too bad if we crash on a file the user selected to play: it's obvious which file caused the crash, the user will just avoid playing that file in the future. However, we would like to add thumbnails so that the user can more easily browse his library. Since we would process for thumbnailing all files the user has transferred to the device, we would be more likely to crash, and if we crash while generating thumbnails, it's far from obvious to the user which file caused the issue, not to mention we crash soon after launching the app, instead of "in response" to selecting a particular file. And once the user relaunches the app, of course we'll have left a "in case I die on that file" message so that we may know we just had an issue, but what then? Either we resume from the file after that, but then we run the risk of crashing a second time on another such file (and while the user will probably forgive us for crashing at launch once, if we crash two times at launch the user will likely summarily discard the app with a 1-star "review"), or we stop generating thumbnails at that point, which is not a very good option.

Being able to spawn a helper process as a sacrificial shell for such standalone tasks that may crash at the worst possible time (like, here, automatic thumbnail generation at app launch) would be very useful (after all, on Mac OS X QuickLook does a similar thing to generate its previews). If a proper high-level API is added to perform this, along with options to further jail the spawned helper process so that it may only access a given file and give its result to the parent process, all the better, but at least provide us the (limited) ability to spawn such helper processes.

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!