On Saturday, 21 October 2017 10:01:26 PDT Konstantin Shegunov wrote: > Assuming my test is failing, which would be the whole reason of writing > tests to check the implementation, right, I would likely end up a situation > where a sibling process waiting for a message from the root process, while > at the same time the root process waits on `acquire` for the sibling > process to signal the semaphore. Ultimately, I'd just end up deadlocking > without a means to tell the root process to run the MPI abort routines > (i.e. stop the whole MPI thing) because the root process is simply waiting > on the system semaphore. That's what I mean by it "doesn't free the thread" > - I'd end up with a deadlocked test program.
Ah, I see your issue. In this case, I'd just have the test harness kill the processes that deadlocked and report the failure. The Qt Continuous Integration system has a timeout of 15 minutes for any test, except tst_QNetworkReply (that one is allowed to run for longer). That way, we don't depend on any internal state being consistent. Like you said, in the case of a failing test, quite by definition the internal state of the application is not what we expected it to be. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
