> This would happen, if lets say we start a child process using QProcess from > main application and don't start the event loop of main application. Now > when child process stops, since main apps event loop is not running, it > doesn't receive the finished hence no one deletes the child process object > on heap. Now if you run ps in terminal, you will see child process as > defunct.
When you say "no one deletes the child process object on heap", I assume you mean the QProcess instance on the heap. If the child process exits, why will the OS show it as defunct? The parent process is still running (due to the infinite loop) and it's child exited (normally or abnormally does not matter), I don't think thats what is happening. >> >> I am trying to create a pre-emptive queue in which each item is a >> download of different priority. In code above Class1 is a downloadmanager >> which runs a forever loop and using mutex and waitcondition I wait for new >> upload being added to queue. Now if a higher priority download is added, >> current ongoing update has to be stopped. I used QProcess instead of a >> thread, to start the download because killing a QProcess is neater. Now >> problem is when an ongoing download ends i.e. its process ends, >> downlaodmanager should receive a finished signal so that it can process >> another download in queue. Is this 'download' over a network? If so why do you need a separate thread/process for it? Have you looked at Qt's networking classes (QNetworkAccessManager, QTcpSocket etc)?? They provide async API's to do network IO. You can still manage your 'premptive queue' based download with it. When a higher priority download is queued, you can always 'abort' the ongoing download and start the new one and whne this one finishes, you can restart the abort one (or whatever your app logic demands). Will that work for you? -mandeep _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest