21

After reading the documentation for NSRunLoop I did not understand very much. I am spawning a secondary thread that has a NSTimer in it that launch every 1sec. Which update a label on the screen with the performSelectorOnMainThread..

However to get it to work I needed a runloop but I do not understand the concept of it?

Anyone who could try to explain it?

Thanks.

Brad Larson
  • 170,088
  • 45
  • 397
  • 571
LuckyLuke
  • 47,771
  • 85
  • 270
  • 434

2 Answers2

32

A run loop is effectively:

while(... get an event ...)
    ... handle event ...;

It runs on a thread; the main thread has the main event loop where user events are processed and most UI drawing, etc, occurs. The documentation explains it in detail.

However, in your case, you don't need a thread.

It sounds like all you are doing is periodically updating a label in the UI; something that isn't terribly compute intensive.

Just schedule your timer in the main thread and be done with it. No need for spinning up a thread, using performSelectorOnMainThread:, or incurring all the complexities of guaranteeing data coherency across threads.

Sorry -- didn't understand your question.

Internally, a run loop works by basically putting a flag in the run loop that says "after this amount of time elapses, fire the timer". No additional threads involved and, better yet, it isn't polling to check the time. Think of a run loop as effectively maintaining a timeline. It'll passively let time elapse until there is something of interest found on the timeline (all without polling -- polling sucks. to be avoided.)

It does mean, though, that a Timer will never be 100% accurate. As well, if you have a timer repeating every second, it'll drift over time.

Also; instead of directly triggering a drawing event. Your timer should invalidate the view that needs updating, then let the underlying objects deal with when it is best to actually update the screen.

bbum
  • 162,346
  • 23
  • 271
  • 359
  • 4
    Timer won't be 100% accurate, but it won't drift over time. Document says "A repeating timer reschedules itself automatically based on the scheduled firing time, not the actual firing time.For example if a timer is scheduled to fire at a particular time and every 5 seconds after that, the scheduled firing time will always fall on the original 5 second time intervals, even if the actual firing time gets delayed. – CarmeloS Aug 15 '12 at 08:01
  • That is new behavior. They used to drift over time. – bbum Aug 15 '12 at 15:56
  • I think you should put the system version from which the behavior changed here so that others, including me, can properly use timers.Would you mind? – CarmeloS Aug 16 '12 at 01:50
  • I'm not sure when it changed. Note that timers are still inaccurate, even with this behavior change. Better, but not perfect. – bbum Aug 16 '12 at 16:23
  • So my question is what is the point of using runloop, if it runs in one thread. – shebelaw Oct 18 '12 at 21:48
  • 2
    Run loops are effectively super efficient looping constructs. You cannot write as efficient of a looping construct because run loops have access to systemic information that isn't otherwise available. Thus, a non-polling run loop is a much **much** better choice than a handrolled while() loop in almost all cases. – bbum Oct 19 '12 at 18:03
14

This page explains it pretty well. FTA:

A run loop is essentially an event-processing loop running on a single thread. You register potential input sources on it, pointing it to the code that it should execute whenever input is available on those sources.

Please treat your mods well.
  • 4,321
  • 1
  • 25
  • 35
  • @Rodrige, Thank you! So it is essentially a third thread that executes code when event happens? – LuckyLuke Feb 09 '11 at 16:57
  • Nope, not at all. The description above is accurate, but -- no -- you don't need a third thread to handle the second thread's timer to post events to the main event loop. – bbum Feb 09 '11 at 17:10
  • @bbum No, I know I don't need to make a third one but it is a third thread working behind the scenes, that was what I meant, is that correct? – LuckyLuke Feb 09 '11 at 17:21
  • 1
    @Andreas Johannessen: Instead of creating a timer and firing up a thread and calling `performSelectorOnMainThread:` you could simply invoke the timer method with `performSelector:withObject:afterDelay:` from the main thread. The method can then recursively call its self to repeat the timer. – Benedict Cohen Feb 09 '11 at 17:25