title: Cocoa, Windows and Threads?
body: <p>On windows, each thread has a message queue, and each message queue will process messages for the windows owned by that thread.
  This means that it is quite simple to write an application where you can create a thread, with a message loop, and one (or more) windows. Ignoring any kind of application issues, one now has application windows that will keep on interacting with the user even if one of the other windows is busy in some kind of modal operation.</p>
  
  <p>Now, in porting the app to cocoa, I encounter, well, Interface Builder. Which is a surprise to  someone who expects to be more in control of window creation and message loop construction. None the less I can see where IB is coming from.</p>
  
  <p>My problem however, lies with the opaque funciton NSApplicationMain(). This - on the applications main thread, automatically creates the applications main window, and runs the message pump, all data driven nicely from the NIB files.</p>
  
  <p>However, this leaves me with a problem: Even if I buy into the idea that Interface Builder is the way to go for making my main app window - and I have figured out enough objective C to create sub windows on the fly - as well as how to create threads - I can's see how to create a message pump in worker threads. I begin to doubt its possible.</p>
  
  <p>Do windows in cocoa even have the kind of thread affinity they do In Win32? i.e. each thread has its own message dispatching loop for windows owned by that thread? Im beginning to suspect that perhaps Cocoa expects all my windows to be 'owned' by the main thread and I just get to offset work (and drawing) onto other threads.</p>
  
  <p>Any clues as to how best to translate a multi window-per-thread Win32 app to Cocoa's paradigms?</p>