objective c - Are NSOperations executed on run-loops? Are there run-loops in every thread? What about OpenGL? -

recently realized don't understand gets run on run-loop , not. here's bunch of questions:

1. is run-loop run on main thread?

2. does opengl main loop underlies entire gui run on thread 0 run-loop? (by analogy, in glut calls drawscene()...)

3. does every thread have run-loop?

4. where nsoperations run?

5. it seems me gcd entirely separate run-loops because c library (libdispatch). how gcd relate main gui run loop?

6. if use nsoperationqueue run multiple nsoperations @ once, each have run-loop or have write code (and why i)?

thanks

questions 1 , 3 same. every thread has run loop, not every thread runs run loop.

a run loop object. objects generally, has state , has methods cause something, based on state. doesn't magically stuff except when invoked. state consists of input sources (like network connections or steam of ui events gets window server) , timers, organized modes. when run loop asked run, sleeps in such way os wake @ particular time or when of input sources ready. goes through of input sources , timers ready fire , calls handler function each. depending on how asked run, may loop , sleep again or may return. that's all.

some parts of cocoa run run loop on behalf. notably, application object runs 1 wait events. on threads other main thread, run loop not typically running.

there's no "opengl main loop" unless write one, in case works write to. glut have main loop , it's built on main run loop (which run loop of main thread, original thread of process). can see implementation in legacy glut code in apple's documentation. -run method.

nsoperations don't run on own. has invoke -start on operation object run operation. else in program, happens on thread. thread caller. operation there operation object itself. may synchronous , of work right there before returning -start, in case runs on thread called. or, might asynchronous , start work on other thread , return -start before work completed.

it common submit operations operation queues (instance of nsoperationqueue). main operation queue (returned [nsoperationqueue mainqueue]) starts of operations on main thread , depends on code in thread giving time run loop. that's done returning out of whatever methods framework has called, can happen when apis run run loop or event loop within them (for example, -[nstask waituntilexit] or -[nsapplication nexteventmatchingmask:untildate:inmode:dequeue:]).

other operation queues run operations on worker threads controls. may or may not involve run loops. implementation detail.

run loops not tied objective-c. there's c api them, cfrunloop. main dispatch queue (obtained using dispatch_get_main_queue()) associated main run loop in program runs it, normal cocoa app. however, can instead associated whatever thread calls dispatch_main() program doesn't run run loop on main thread. whether non-main dispatch queues related run loops is, again, implementation detail (but aren't ;).

nsoperations don't have run loops, because run loops associated threads. when nsoperation running, runs on thread. threads have run loops associated them, but, said, not threads run run loops. not "need" write code related run loops nsoperation. generally, shouldn't. people have operations run run loop of thread they're on in order allow run-loop-based api notified when source ready or event has occurred. there's way they're trying more efficient resources.