Hacker News Reader

Comment by nicklo | Hacker News Reader

This strategy is also encouraged by best iOS development practices (main thread never works on GUI).

Edit: 'main' as in the one doing the one doing the work, in the same spirit of the original post. In truth, the true main thread that runs in main() is where all the iOS GUI work happens. Apologies for the confusing wording.

View on HN

This is not only completely wrong, it's dangerously wrong. It is in fact wildly unsafe to touch the GUI from anything except the main thread. It's all the non-UI stuff that you should shove onto another thread.

Depends on what you call "main thread" - maybe he's saying worker thread that's doing the "main code" shouldn't be doing GUI

In other languages / frameworks, "main thread" may have flexible semantics, but in the land of iOS, UIKit defines the term "main thread" to have one specific meaning.

So... GUI work goes on its own thread, however that works out

Nope, the term "main thread" is very explicitly defined by both iOS and OS X. Not only in all the frameworks (e.g. NSThread, NSRunLoop, etc. all explicitly define "main thread"), but even at the system level. OS X and iOS have a pthread function `int pthread_main_np(void);` that returns non-zero if the current thread is the main thread (meaning the initial thread that the application was launched with), and that is the thread that all UIKit (iOS UI) and AppKit (OS X UI) code must be running on.

This is backward. Since UIKit is single threaded, the main thread must work on GUI: the best practice is that nothing except GUI work should happen there.

You're not being charitable enough to the comment... you two are in completely agreement with one another if you only changed the meaning of the word "main". It's clear the grandparent meant "the thread that's doing the work."

It's really difficult to get to that meaning, because "main thread" is what you call the thread where main() is invoked and which is where all the GUI calls must happen. You can't use a common term in context to mean something different from its common meaning and expect people to follow.

And yet it was perfectly obvious what was meant. If you just assume the person who made the comment is not stupid/rambling (difficult concept, I know...) it is not difficult to get the meaning at all.

I think it's just a "my environment" bias thing going. I don't work on iOS and I immediately understood what was meant by the comment. Of course, the "my environment" bias may also include a degree of the "other" is not as bright as me.

You say it was perfectly obvious, I say it's almost impossible for someone steeped in iOS development to understand any way other than the way I said. Even given a huge amount of charity to the poster, the best I can do is "I have no idea what they mean by this."

How come we have to give this person the benefit of the doubt to the point of understanding a term to mean its exact opposite, but you don't have to give us any of that?

Thank you for this. I see now how my wording was unclear, but this is exactly what I had meant. Sorry for the confusing word choice.

except on iOS GUI thread kinda has "main" attached to it, main_queue

Changing a fundamentally well-defined term (main thread, i.e. the one on which main() is called which is running the core event loop for the application process) to be an incorrect opposite is rather fundamental when one is explaining an iOS best practice.

Not just iOS. Pretty much all UI frameworks frown upon doing heavy work on the main thread.

Same was true of Java. Sun called it the "AWT event dispatch thread." Any process that does computation or blocks on IO should run in a separate thread and periodically post updates to the UI via an event queue.

https://docs.oracle.com/javase/7/docs/api/java/awt/EventQueu...

Reply on news.ycombinator.com