If one destroys a running QThread, so far the behavior has been to crash
(à la std::thread) -- assuming the thread hasn't already signalled that
it has finished. This behavior is hostile to solutions such as using
QThread::create(), which always require a wait() before destroying the
thread object.
We can use the opportunity to change the behavior without breaking any
valid code. Instead of crashing, inside QThread's destructor we can ask
the new thread to quit, and then join it (à la std::jthread). This
simplifies the implementation of long-living runnables and the code that
manages them.
Deploying this solution for the whole QThread class may not be entirely
painless. While no correct code would work differently with the proposed
changes, incorrect code that deletes a running thread would no longer
crash "loudly" -- instead, it might deadlock "quietly", have memory
corruptions, etc.
Hence I'm limiting this approach to only the threads created by
QThread::create(), at least for the time being. This also side-steps
perhaps the biggest problem of generalizing the approach, which is that
placing such interrupt+join logic into~QThread's destructor would cause
it to be run _after_ a QThread subclass' own destructor has run,
destroying the subclass' data members too early. This might create
an antipattern if one chooses to subclass QThread. With create(), a
subclass in question exists, and it indeed has NSDMs, but it's entirely
under our control (in fact, I'm placing the logic just in its dtor).
[ChangeLog][QtCore][QThread] Destroying a QThread object created by
QThread::create() while the thread that it manages is still running will
now automatically ask that thread to quit, and will wait until the
thread has finished. Before, this resulted in a program crash. See the
documentation of QThread::~QThread() for more details.
Change-Id: Ib268b13da422e277ee3ed6f6c7b2ecc8cea5750c
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
84fba93ebb