The simple solution is to subclass QThreadPool
and add an aboutToWait
signal to that class. The signal would need to be emitted in the destructor. You can then hook up the signal to the controller's cancelAll()
slot.
For this to work, the pool must be declared after the workers list!
Suppose you destroy the controller (this
). The following happens:
Body of
this.~Controller
executes.At the end, the object is still an instance of
Controller
. Now it has to be torn down into an instance of the base class. The members will be destructed in reverse of the order of declaration.threadPool
is destroyed first.threadPool.~MyThreadPool
emitsaboutToWait
.this.cancelAll
runs, since it's directly connected. The call originates in the moc-generated implementation of the signal method. It lets the workers know that they should stop.Remainder of
threadPool.~MyThreadPool
runs, and members (if any) are destructed in reverse order of declaration.this
is now an instance ofQThreadPool
.threadPool.~QThreadPool
runs and waits for the workers to stop. As each worker stops, thecontroller.onWorkerDone
is invoked, since it's directly connected to relevant thread pool's signals. Eventually,threadPool.~QObject
runs the pool is fully destructed.workers.~QList
runs.this.~QObject
runs.The controller is fully destructed.