{"id":31952,"date":"2021-03-22T15:49:13","date_gmt":"2021-03-22T19:49:13","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=31952"},"modified":"2021-03-22T15:49:13","modified_gmt":"2021-03-22T19:49:13","slug":"how-netnewswire-handles-threading","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2021\/03\/22\/how-netnewswire-handles-threading\/","title":{"rendered":"How NetNewsWire Handles Threading"},"content":{"rendered":"

Brent Simmons<\/a> (Hacker News<\/a>):<\/p>\n

Every notification and every callback happens on the main thread.<\/p>\n

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.<\/p>\n

[…]<\/p>\n

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.<\/p>\n

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.<\/p>\n

[…]<\/p>\n

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.<\/p><\/blockquote>\n\n

Brent Simmons<\/a>:<\/p>\n

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.<\/p>\n\n

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<\/em> the fix but now, actually, there’s a new crashing bug, which might have been triggered by that “fix”… and so on, forever.<\/p>\n\n

Developer morale is important!<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n