How NetNewsWire Handles Threading
Every notification and every callback happens on the main thread.
Though a given object (or small system) may use a serial queue internally, it never, ever lets that fact leak out beyond its own boundaries.
[…]
Some developers I’ve known seem to think that being good at concurrency makes them badass. Others seem to think that senior developers must be great at concurrency, and so they should be too.
But what senior developers are good at is eliminating concurrency as much as possible by developing a simple, easy, consistent model to follow for the app and its components.
[…]
I know you’re worried about blocking the main thread. But consider this: it’s way easier to fix a main-thread-blocker than it is to fix a weird, intermittent bug or crash due to threading.
It also improves the experience of our developers, who can concentrate on the feature they’re working on instead of on how the feature can live safely in a multithreaded universe.
Best of all: nobody is spending time tracking down a maddening threading bug that never happens on their machine, and then implementing a speculative fix — only to find later that it’s not the fix but now, actually, there’s a new crashing bug, which might have been triggered by that “fix”… and so on, forever.
Developer morale is important!
Previously:
2 Comments RSS · Twitter
I’ve noticed that NetNewsWire is zippy most of the time, but the UI freezes when I select a folder with a lot of unread articles. This would seem to explain that behavior.
@Fred I’m not sure there’s a connection there. Without prefetching, when you click on the folder it’s going to have to search the database, which could be slow. While waiting for the search to complete, the main thread has to either block or display some sort of placeholder. It seems to do the former, but either could work with this threading model.
