diff options
author | Bradley T. Hughes <bradley.hughes@nokia.com> | 2010-10-29 13:04:46 (GMT) |
---|---|---|
committer | Bradley T. Hughes <bradley.hughes@nokia.com> | 2010-10-29 14:02:16 (GMT) |
commit | 0c643b179c5154c50b61dba421016b7b48794720 (patch) | |
tree | ee7c2f59dd970d90d7c546ac52e6cd801898280d /tests/auto/qscriptengine | |
parent | e7b9fb2e87641a36301babf457056b3350f0431c (diff) | |
download | Qt-0c643b179c5154c50b61dba421016b7b48794720.zip Qt-0c643b179c5154c50b61dba421016b7b48794720.tar.gz Qt-0c643b179c5154c50b61dba421016b7b48794720.tar.bz2 |
Simplify object lifetime management when moving objects to a QThread
The documentation for Qt::AutoConnection states is a signal is emitted
from the same thread as the receiving object, the connection should
behave as Qt::DirectConnection. The actual behavior prior to this commit
was different from the documentation; if the signal was emitted in a
thread different from the sender's thread, then we would queue (which is
now corrected). By making the behavior match the documentation, it is
now possible to connect QThread's finished() signal to an object's
deleteLater() slot and the slot will execute when finished() is emitted
(previously it was queued).
QObject::deleteLater() uses a posted QEvent::DeferredDelete event to
trigger deletion of the object. In QThread, after emitting the
finished() signal, we now send all pending DeferredDelete events to
ensure that all pending deletions happen. We have precedence for this
behavior, QCoreApplication::exec() does the same thing after emitting
the aboutToQuit() signal.
Reviewed-by: joao
Reviewed-by: olivier
Diffstat (limited to 'tests/auto/qscriptengine')
0 files changed, 0 insertions, 0 deletions