Quote Originally Posted by MattPhillips View Post
wysota, you're right--none of those will stop the execution flow. So if the OP really needs to 'freeze' things then they won't work. But I would have thought the natural way to set up what the OP is doing would be to have the start() call be the last line in the method and then return control to the main loop, waiting for an appropriate signal. All visible gui's can be setEnable(false)'ed if need be.
Assuming there is a ui involved... All the code we've seen supports a claim that if he just ends the method at this point, nothing will happen as the QProcess object will go out of scope.

4) Use a QTimer to periodically check the state of the child process after it has been started.
That's a really bad idea.

I looked at QSystemSemaphore. At the time the main app would try to acquire a resource, the child app will likely not even be running yet. Hence there will be an available resource, the main app will take it, and execution will continue in the main app. As I'm seeing it anyway--how would you do this?
Wrong. You can (and in fact have to) initalize the semaphore to 0 and also acquire the semaphore only after the child process is already scheduled by the OS to be started (it does not have to be actually started yet). Then the order of events doesn't matter - the parent will only be able to continue after the child releases the semaphore.