Erica Sadun (of iPhone Developer’s Cookbook fame) notes that the Safari 4 Beta application bundle contains a standalone utility for the generating previews of web pages that appear in the top sites view. Rather than generating the previews from the main Safari application process, previews are generated in the backround using a separate process.

My own ASIWebThumbnail uses a similar approach - you add the preview generator application to your bundle, and use the provided API (which talks to it using an NSTask behind the scenes) to talk to it. If you want to generate web page previews in your own Cocoa applications, without worrying about whether some naughty script or plugin will crash your app, you might want to give it a try. (It can also be used standalone from the terminal or from your own scripts)

In the Ars Technica piece, John Siracusa suggests this approach is, in Sadun’s words:

“...a vote of no confidence in Mac OS X’s concurrency frameworks, particularly when used in conjunction with a big library like WebKit.”

Apple notes that WebKit document loading is not safe to use on background threads anyway, which I’m guessing means they’d be looking at UI slowdown if they tried to generate the previews from the main application process. Webkit is a large framework that is not exclusively tied to Mac OS X, so I’m sure making it thread safe would be a massive undertaking.

Such a large piece of software is also bound to contain some bugs, and the modern web is basically one giant blob of unexpected input, waiting to crash your software in multifarious ways. Additionally, browsers have to contend with Adobe Flash third-party plugins that might contain crashing bugs. Even if Webkit were thread safe, why take the risk for something like as trivial as web page previews?

Of course, Apple weren't exactly the first to realise that a multi-process browser might offer some stability advantages. Surely it won't be long before both Safari and Firefox start handing off responsibility for each web view to a new process, as Google and Microsoft have done.

NSOperation and NSOperationQueue, introduced in Mac OS X 10.5 and also available on iPhone, offers a nice model⁽ⁱ⁾ for handling sets of tasks across multiple cores, but they still require you to have a reasonable understanding of threading concepts like locks except in trivial cases. If your application has a UI, you’ll also generally need to take care to update it only on the main thread. Given that most modern desktop computers have at least two cores (more if you count the GPU), surely we must be overdue for some easier methods for our to software get the most out of the available hardware?

1. Possibly a dangerous one, but I'll take the risk. It sounds as though the bugs are rarely encountered, and given how much coverage was given to the NSOperation stuff when Leopard came out, I'd imagine they are likely to be fixed at some point.

Aaaron Hillegass’s definitive Cococa Programming For Mac OS X touches on some of the problems surrounding multithreaded programming, summarised with the the following pearl of wisdom (page 406 in 3rd Edition):

“Although not as glamourous as multithreading, multiprocessing is probably more useful in real life.”

When I first saw this, I wondered why he would suggest such a thing. Surely, the standard way of getting desktop software to do more than one thing at once is using threads, not using multiple processes?

At last, I think I finally understand his point.