How NetNewsWire Handles Threading | Hacker News Reader

How NetNewsWire Handles Threading

inessential.com

41 pointszdw11 comments

Netnews wire users show up on my dashboards as doing an abnormal volume of parallel requests. Like >200 all at an instant from a single user. Chrome has a limit on the number of parallel requests but NetnewsWire lets any quantity of parallel requests off.

It annoys me because I have rate limits and so the NetNewsWire RSS users get annoyed at me but I feel its NetnewsWire is moving too fast and breaking things, WDYT? I feel this situations is a side effect of making speed the #1 priority.

I don't really want to complain too much as I am happy people are using RSS.

I figure this might at least be cause to present your case the developers?

I suppose it matters why you have rate limits. Just to have them? As a soft failure case before hitting some harder boundary, like memory or fd exhaustion?

Threading on Apple's platforms is interesting because GCD exists and makes doing things concurrently really easy. I think when it came out there was a large push to get all your code off the main thread, spin up queues for background work, use all the new cores in your processor efficiently, but these days I'm seeing a lot more of a walking back of this as people invariably use the primitives incorrectly and shoot themselves in the foot. Data races are easy to create and post-ARC one of the easiest ways to get memory corruption; even when your code is "correct" that doesn't mean that you aren't suffering from performance problems due to priority inversion or thread explosion or poor synchronization primitives. These days, I suggest people keep things on the main thread unless they 1. really have a good reason to move things off of it and 2. understand which primitives they are going to use and what their tradeoffs are.

> but these days I'm seeing a lot more of a walking back of this as people invariably use the primitives incorrectly and shoot themselves in the foot

Interesting, on which eco-systems you see this happening (iOS/MacOS) ?

This is a duplicate of https://news.ycombinator.com/item?id=26528543

When did using a thread become some kind of inscrutable black magic?

As domeone coming straight out of college, I disagree with your premise that threading is not accessible anymore. However, one possibility is that a proliferation of new languages brought with them new threading models and runtimes that all behave slightly differently. This makes many of the models look foreign.

Nothing demonstrates why threading can sometimes be black magic better than someone misinterpreting a one sentence, plain English post :)

I read the GP's post as implying that it is not actually that hard. But maybe they did mean that it has changed over time and gotten much more difficult and they're legit asking when that happened?!#

Imagine this level of simple misunderstanding but applied to reading someone else's threading code!

The proper question is, when did threads stop being some kind of inscrutable black magic?

And the answer is, if you consider the whole of the programming space, that it's still a work in progress. There's a lot of good ideas in various places, but I'm not sure I've seen it unified into one coherent whole in any one language in such a way that it's simply a solved problem for virtually no effort. Every A-list or B-list language I know either has easy concurrency that can still get you deep in trouble (like Go), or "solves" the concurrency problem but at a fairly steep cost to the programmer (like Haskell).

Arguably Pony is the closest I've seen, but that's not even B-list yet, that's an "up and comer".

It's not, but it's needlessly complicated for what most people need to use threads for - async background tasks like fetching a resource or (as mentioned in the article) parsing RSS off the main thread.

I've done threads in the past, but for a good while now I've not had to do much thinking about async code thanks to advancements.

Reply on news.ycombinator.com