Removing connections and resizing the signal vector now
happens in a way that will not interfere with activate(),
as the old objects won't get deleted if we are somewhere
inside a signal emission.
This means that we don't need to lock the senders mutex
in activate anymore, as long as the reference counting
on the ConnectionData is atomic and we are in the senders
thread.
This implies that we now need to lock the receivers mutex in
queued_activate() abd blocking queued activation to ensure
it hasn't been deleted while we are emitting.
In addition, some precautions need to be taken to not read
from the receiver without holding the lock, as it could get
deleted while we're activating (if it's in a different thread).
To make that possible store the receivers thread id in the
connection data.
Use atomic pointers for all variables that can get modified
with the signalSlotLock() held and that are being read
without the lock being held.
This gives us a very nice additional speed improvement
for signal emissions.
without change with change
string based connect: 3287 2436
pointer based connect: 3941 3265
not connected: 403 400
disconnected: 460 489
5 slots connected: 9112 4515
Change-Id: Ib7324bb74c389dcc3b6581a03c31469a6e589fc2
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
And use it to clean up the reimplementations in Qt DBus.
Change-Id: I8e3fe35e8db6405cbcbfb45b42a8f2efecc1cef0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Put all connections that get disconnected into a singly
linked orphaned list.
Whenever the refcount on the connectionData drops down to
one, this list can safely be cleared, even with the planned
removal of locking in activate().
Use an id integer in the connection to acoid activating newly
added connections.
Fixes: QTBUG-72649
Change-Id: Ide3d116ae7fc9ca497598c1c2b71d43b4339c92d
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
When checking whether a slot is connected to a signal, we need to
hold the signalSlotLock to be sure about the answer, or we can
get crashes when a connection gets removed while doing the check.
The check in activate() can handle some uncertainty as it's only
a shortcut to the longer path.
Fixes: QTBUG-74604
Change-Id: I3fc822455fbadc0223ef68632f5fb3df3ff3e86d
Reviewed-by: Aapo Keskimolo <aapo.keskimolo@qt.io>
It Q_ASSERTs that argv is not a nullptr, so it would fail when an
unconnected signal with 0 arguments was emitted.
Change-Id: I5dd810fbeea5b6b511eff4705efdaa6a55739604
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If you enter a nested event loop, cause a deleteLater(), exit that event
loop, then enter a new one, the nesting count will be the same so those
are legitimate targets for deletion.
Task-number: QTBUG-73432
Change-Id: Id98140e1c2f0426cabbefffd157f975b5e291ccd
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Conflicts:
tests/auto/widgets/itemviews/qheaderview/tst_qheaderview.cpp
Added tests/auto/testlib/selftests/expected_crashes_5.txt to work
round the output of the crashes test (which exercises UB, see
QTBUG-73903) being truncated on one test platform.
Change-Id: I9cd3f2639b4e50c3c4513e14629a40bdca8f8273
Replace null and '\c nullptr' with \nullptr in the documentation.
Change-Id: Ib9e0cfc2eb2830b213e6523773603d56180b0998
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Add a simple private QBasicMutexLocker class, and let the
QOrderedMutexLocker operate on a QBasicMutex.
This allows the compiler to inline more things when handling
connections and speeds up activate() a bit more.
without change with change
string based connect: 3621 3368
pointer based connect: 4341 3919
not connected: 433 437
disconnected: 551 538
Change-Id: If979337891178aaeb0b3340b6d4f68b6f86b0260
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
The main difference is that QObject itself also holds on reference
on the structure.
Also rename the orphaned flag to objectDeleted for clarity.
Change-Id: Ief9b9ff9c8b9cc3630dcfd29806ed24cd07150e4
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Adn create that data structure on demand on the heap.
This reduces the size of QObjectPrivate if there are no
connections. If we have connections, it'll use the same
amount of allocations and memory as before.
Change-Id: I900f6980a2cd8a5f72c3ad18697b5dd49100217d
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Squeezes another percent of performance out of
QMetaObject::activate().
Change-Id: I620b8c578681280efcc9bec50cfb1020d2afc928
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Refactor activate(), so that we eliminate almost all
checks for signal hooks in the common case.
Here are the benchmark numbers showing the improvement
for 100M signal emissions
without change with change
string based connect: 3836 3693
pointer based connect: 4571 4510
not connected: 479 433
disconnected: 559 522
Change-Id: I394e6ea5d5bc96e298e8cc0c763eed78c8041876
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Measurements show that it's just almost as fast to simply query
the connectionlist directly and avoid both the memory
overhead of the bitfield and the associated bookkeeping.
For connected signals, the difference is not relevant at all.
With a signal that was never connected, removing the bitfield will
cause signal emission to be ~2.5% faster. And if you ever disconnect
from a signal, the bitfields might not be accurate and this can
cause a major slowdown.
Here are some numbers to validate this. All times are measured
in ms for 100M signal emissions:
without change with change
string based connect: 3817 3836
pointer based connect: 4552 4571
not connected: 493 479
disconnected: 2113 559
Change-Id: Ia2c85036afaa7f991b883c8ff812f69cf4580f7e
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: hjk <hjk@qt.io>
And simply emit the signal spy and tracing callbacks in
that code path as well.
Change-Id: I17f65055c7044caf1be58fac94bb7fe3487f3060
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Try to better describe what it is and what it does. Also mention
its strongest use case.
Change-Id: Ib5c3e8a3c9b96169c139c5d7e8995a6a49d7d5e1
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Replace 0 with \nullptr in the documentation.
As a drive-by also replace some 0 with nullptr in the corresponding
code.
Change-Id: I101a61f5fad71cadb73bba9a8fd5dce6cc0836d0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
The meta object system stores enums as signed int, probably for
performance reasons. This is good enough for about 99% of the use cases.
If you try to register larger types and then access them through the
metaobject system, you can get undefined behavior.
Task-number: QTBUG-71947
Change-Id: I16b395547c22fad10b476c2c2a0768538db0a20e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QKeyEvent's detailed description already documents this:
"A key event contains a special accept flag that indicates whether the
receiver will handle the key event. This flag is set by default for
QEvent::KeyPress and QEvent::KeyRelease, so there is no need to call
accept() when acting on a key event. For QEvent::ShortcutOverride the
receiver needs to explicitly accept the event to trigger the override.
Calling ignore() on a key event will propagate it to the parent widget.
The event is propagated up the parent widget chain until a widget
accepts it or an event filter consumes it."
However, someone looking at eventFilter() won't see this, resulting in
the shortcut not being consumed and propagating elsewhere, so mention
it in the docs for eventFilter() too.
Change-Id: I14fece52133be641ccdabd81f75706cd10b64669
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Avoid a couple of branches in QMetaObject::activate().
Change-Id: I15394d1ede48be771797fc5f64a5de6387e6f814
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Use the overload using QRegularExpression instead.
Change-Id: I1bf468b248c0a3f5b2304b1831379a127093df06
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
Amends a952fd7d5b03ce1968ec58871fbb8b3600895900.
The mentioned commit started to skip QObjectPrivate::isSignalConnected() call if
the connectionLists are dirty, which lead to tst_qqmllanguage::receivers() test
inside qtdeclarative breaking.
Declarative signals were not checked if that function was not called. It
previously also wasn't called for signals higher than 64. Fix that by checking
for declarative signals after the connectionLists search is unsuccessful.
Fixes: QTBUG-71550
Change-Id: Ifcb5fdd0dc9a6b14b9f448a016fd09356a55b985
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
The bitmap cache for the first 64 signals being connected was only set when the
connection is added. It was never unset when the connection was removed.
Internal use of the connectedSignals bitmap is not hurt by it occasionally
saying a signal is connected even though it is not, since the purpose of those
checks is avoiding expensive operations that are not necessary if nothing is
connected to the signal.
However, the public API using this cache meant that it also never spotted
signals being disconnected. This was not documented. Fix the behavior by only
using the cache if it is up to date. If it is not, use a slower path that gives
the correct answer.
To avoid making disconnections and QObject destructions slower, the cache is
only updated to unset disconnected signals when new signal connections are
added. No extra work is done in the common case where signals are only
removed in the end of the QObject's lifetime.
Fixes: QTBUG-32340
Change-Id: Ieb6e498060157153cec60d9c8f1c33056993fda1
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
We need to override this snippet for the documentation
we generate for Qt for Python, and it is easier to have
it on a separate file.
Task-number: PYSIDE-801
Task-number: PYSIDE-691
Change-Id: Ideb5b6af25024279f167137d3b65660bb9c96a7e
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Weak pointers are zeroed before destroyed() is emitted. This makes sense
because the signal is called "destroyed()", not "aboutToBeDestroyed()",
and the code has been like this for a long time.
Change-Id: Ic852fe354405e328d1922a75931e7eb7bf651b26
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add it to configure.json and replace all occurrences of QT_NO_THREAD
with QT_CONFIG(thread). Add conditions for other features that depend
on thread support. Remove conditions where we can use the QMutex and
QThreadStorage stubs.
Change-Id: I284e5d794fda9a4c6f4a1ab29e55aa686272a0eb
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
[ChangeLog][QtCore][QObject] Fixed a bug in setProperty() that caused a
property change not to take effect if the old value compared equal using
QVariant's equality operator, but the values were not strictly equal.
Task-number: QTBUG-69744
Change-Id: I00e04a465fcf4fc1a462fffd1547885861a07a64
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Change-Id: I4f9033660c06686d7b499ec6d28be2c3b64353e2
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Martin Smith <martin.smith@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Link to the data ownership section of the QML documentation to elaborate
on the special rules that apply for invokable functions that return
QObjects.
Change-Id: I41ea9089468c9505807cf1fde22be759b397a6d3
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
