What's the real point and benefit of having an Run Loop?

When reading the apple docs about multithreading, they talk a lot about Run Loops. What's the point of creating a Run 开发者_运维知识库Loop? Is that for re-using a user thread multiple times? In which exemplary situations is a Run Loop a good idea?

How does this Run Loop relate to a thread? Lets take as an example the main run loop of an iPhone OS app. When the user touches the screen, it fires an event. Does the run loop re-use the main thread in order to handle the event with some code? Or does the run loop create a new thread every time an event occurs?

Run loops are a good idea if you want your app to work on a modern, event-based UI. I.e, anything since DOS.

All desktop OS runtimes from Cocoa to .NET to REALbasic to whatever give you a main run loop for free. A run loop goes round and round, checking for events and delivering them to where they need to go. Without it, you wouldn't get mouse, keyboard or other system events. When the main run loop terminates, your app will automatically terminate as well.

Normally you don't need to do anything with the main run loop, or make new ones. Showing a modal panel in Cocoa sometimes internally creates a run loop for the panel depending on the behaviour. This halts the main run loop so only the panel gets events.

The main thread in an iPhone or Cocoa app runs the main run loop, and all events are delivered on the main thread. Any extra threads you create don't have their own run loop unless you create one yourself.

The run loop is the main construct that keeps your application running.

The application loops through the run loop managing events, timers, et cetera until the application is quit.

The run loop conceptually is an endless loop:

while( !quit ) {
    // Handle events
    // Listen for input
    // Manage timers
    // ...

}

Unless you create additional threads you don't need to create run loop objects explicitly. A thread can have it's own run loop where it can independently manage it's own events, timers and handle input.

Imagine your application communication with a slow remote service. A thread could be set up to handle the communication with the remote service. The threads run loop would take care of reading data as it becomes available from the remote service and perhaps processing it before passing it upstream when the data is completely read from the remote service.

Check out the Apple documentation at developer.apple.com.

I was terribly confused about Runloops as well. They work more like an event queue or notification center than anything loop related. Because they are called loops I tend to think of threads or a thread in a loop. There is a thread that executes work that is added to the run loop and that is different than the actual loop. Just like iKenndac says you need to understand the concept if you want to write code for any modern UI that is more advanced than DOS. Everything from Swing to SWT to J2ME to Blackberry to iPhone includes this concept. They are just named differently. Here's the confusing thing. You can create new RunLoops and add stuff to them. The stuff added will sit happily idle, never actually running because you have to create the actual thread to pump the RunLoop. I'll shutup here because I'm still learning CocoaTouch and the SDK and I don't wanna confuse further.