Sorry I cannot post proprietary codes here. Basically, it's a Mac GUI application. The codes were not properly designed to make use of the asynchronousity concept. Everything is processed on the main thread, and it's impossible to change the design overnight. Therefore, I'd like not to go with the dispatch_async(…) solution.
The context of the problem is: I have a time-consuming task that runs on the main thread. While the task is being processed, I try to update/redraw a progress bar (NSProgressIndicator) based on the task's completion percentage (from 0% to 100%). However, because the task runs on the main thread, the main thread is blocked, and any update/redraw event in the event queue has to wait until the main thread has a chance to look at it, so the progress bar is not updated/redrawn at all during the task execution.
The solution I'm thinking about is to create another app (with an .exe file) that handles the progress bar drawing. From the main app, I'll create another process and have that process execute the other app. The task's completion percentage can be sent from the main app to the other app by using the Boost inter-process message queue.
I'm hoping to hear about both advantages and disadvantages of this solution, so any thoughts will be much appreciated!
You can do that from a thread in the same process as well. Interprocess message queues still work, though any threadsafe solution would suffice.
In general, it can be worth running some non-trivial tasks out-of-process. The kernel-level process-isolation has benefits that threads can never have:
Therefore when dealing with untrusted inputs or unreliable third-party library code you can gain stability guarantees for the main process.
However for your purposes it sounds like severe overkill.