One of the surprising things about the multi-processor era is how poorly some applications handle it.
Case in point: I adore Shiira and use it as my everyday browser, and overall it’s a compelling browser, even if I do have to fake the user-agent to get annoying Ajax-based sites to let me in. I think of it as “Safari with the training wheels taken off”. However, printing in Shiira is fraught with peril. More often than not, printing a page on my dual-G5 crashes the application.
The funny thing is, printing almost never crashes on my G4 PowerBook.
While I was dumping some photo pages to PDF in preparation to letting my .Mac account expire (face it: .Mac sucks, and wouldn’t be worth $20 a year, to say nothing of $100), I found that I was printing them without crashes on the PowerBook. Initially, I thought it might be the processor generation difference, but then I thought to turn off one of my G5’s with the Processors system preference:
Surprise. Much less crashing. Maybe 1 time out of 20. Which is still too much, but I had been crashing 9 times out of 10.
Seems like it has got to be a concurrency bug. What made me think to turn off a processor goes back to when I had the opposite problem working some QuickTime stuff with a client — showing a certain config dialog is a 100% crasher on my Core Solo mini, but my client has a Duo and hasn’t had a problem. I was going to congratulate myself for buying the crappy single-core mini and accidentally exposing myself to the bug, when someone in a talkback reminded me I could have gotten the dual and then just switched off one core to test single-core operation. Oh well, the minis are supposed to be an easy CPU upgrade, right?
I think developers are just coming to grips with some of the implications of multi-CPU development on the desktop. Mastering threading and understanding concurrency is a bigger deal now than it used to be. For example, Java desktop developers often kept their stuff on the main “event dispatch” loop for reasons of performance and thread-safety, but that leaves a lot of potential CPU time wasted in the multi-core era. Smart programmers are going to have to get into the habit of putting work on new threads and having those threads call back to event-dispatch when they’re done. I think the Cocoa case is pretty similar, except that you’re dealing with the care and feeding of AppKit’s main thread… but I haven’t done that much Cocoa programming, so the Java analogy may not be particularly appropriate.