Question

As my first Mac application, I'm building an app that displays incoming MIDI timecode. Therefore, I am having an instance of the RtMidi "library" which wraps the MIDI in and out stuff. The Mac OS Core MIDI callback is in blank C and is called on multiple threads internally. The RtMidi stuff in in C++ and forwards this multi-threaded call to one single (the main) thread.

As I need a Cocoa function to notify other classes that a new MIDI timecode has arrived ( which happens about every 7-9 ms ), I implemented a Singleton which all necessary classes observe.

So, the order in which the functions are called is :

    Core MIDI callback -> RtMidi function -> user callback -> Notification ( via Singleton )

Basically, this works!

The problem is that I right now have everything on the same thread ( the main thread). If I post a notification from the MIDI callback and the called functions take longer to complete than the above mentioned 7-9 ms, the Core MIDI callback gets blocked which causes the whole application to freeze. I tried debugging and it seems that there is some kind of deadlock occurring.

Anyone has some directions on how to implement multithreading in this case? As I also do UI updating in the notification observers, I would need all notifications to appear on the main thread. What I don't understand is how everything goes with C / C++ / Objective-C in this particular case.

Was it helpful?

Solution

I would suggest that at the stage that you forward your call from your background thread to the main thread that you do so in a non-blocking manner, if possible. For example, you could use performSelectorOnMainThread:withObject:waitUntilDone:, passing NO for the last argument, or some other mechanism like dispatch_async(dispatch_get_main_queue(), ^{ ... }). This will prevent your background thread from getting blocked, and allow the UI to be updated whenever it has time to do so.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top