Mac Development : 2

Month Three : Week Four


        This week I encountered a big issue with the Mac of development that really brought development to a standstill. The issue is that in order to kick off the event loop for an application on Mac, you must call [NSApp run]. This function will begin to take in and process message coming into the window. However, the big kicked is that on Mac this is a blocking function, whereas on Windows and Mac the window can be created and its events handled on a separate thread without blocking. This meant that my OpenWindow function on Mac never returns because it calls [NSApp run] at the end to open the window and start the loop. Initially I figured I could just launch the window on a secondary thread, but the I got hit with the realization that any Cocoa function MUST be called on the main thread of the application no matter what. This is a big problem because the entire test suite resides on a secondary thread to begin with.


       The answer for this one was first to figure out what [NSApp run] really does. By looking directly at its source code I was able to discover it was simply getting the next message from the NSApp and sending to off and then updating the window. So, I created my own [NSApp run] equivalent that does the exact same this but breaks when the event queue is empty so the thread can continue running. However, this didn't fix the issue completely because getting the next event is a Cocoa function which must be ran on the main thread. Through a lot of research on this issue I finally found to separate ways to send a whole block of code to the main thread from any other thread. By using this method of code dispatching and my custom run function I was able to sufficiently mimic the functionality of the Windows and Linux side GWindow.