There are two cases:
In a BlockingQueuedConnection, QMetaCallEvent doesn't allocate memory
and instead passes already existing pointers through. A QSemaphore
is used to serialize data access between threads. So the constructor
taking a QSemaphore can be simplified to only accept an existing arg
array.
In a QueuedConnection, QMetaCallEvent needs to make deep copies of
the arguments, and memory needs to be allocated based on the number
of arguments. The previous code put the burden of memory allocation
on the code generating the event, while the memory was free'd by
~QMetaCallEvent. Instead, make it QMetaCallEvent's responsibility
to allocate and free the memory as needed, and adjust the code
generating QMetaCallEvents.
We can allocate the memory for types and pointers to arguments in a
single block, starting with the space for the array of void*, followed
by the space for the array of integers to avoid byte alignment issues.
By pre-allocating the space that's needed by three arguments, we can
avoid all mallocs for the majority of QMetaCallEvents.
Until this change has propagated through qt5.git, we need to keep the
old API that is still used by QtDeclarative around. Once QtDeclarative
has migrated to the new API, it can be removed.
Change-Id: Id7359ffc14897237ea9672dabae9ef199a821907
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Use the standard tool instead of self-made stuff that cannot decide whether
it wants to be a scoped pointer (why take()?) or a movable one (why no move
special member functions?).
Take advantage of C++11 local structs for pulling the custom deleter into
the scope where its only user is located, too.
Change-Id: I7e097a59edef9adc8455504ae94b8df0f8b9e5d2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Because it is. It's just QCoreApplication::postEvent(), which is thread-safe.
It also _has_ to be, because we recommend to use deleteLater() to delete
QObjects that live in another thread:
Quoting the ~QObject() docs:
> Warning: Deleting a QObject while pending events are waiting to be delivered
> can cause a crash. You must not delete the QObject directly if it exists in
> a different thread than the one currently executing. Use deleteLater()
> instead, which will cause the event loop to delete the object after all
> pending events have been delivered to it.
If deleteLater() is not thread-safe, it cannot be used for one of its intended
purposes.
Change-Id: I333d506b42bdfcdff00fe6cefa234c21865625a6
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This appears to have come to some fame on the internet, so better fix
the implementation before we remove it in Qt 6.
Change-Id: Ia37ca89105b13bea1ffcdce8b2e8cd957b7bd108
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The old code used the implicit conversions from QAtomicPointer<T> to T*
and vice versa. The semantics of these differ from the ones std::atomic
uses, so we're going to deprecate these, like we did for load() and
store(), too.
This patch fixex some users of these APIs before we deprecate them.
Change-Id: I0a88bb1c359392538bb64b511bfc62381a56a468
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A recurring problem with the Q_NAMESPACE macro is that it declares
an object (staticMetaObject) in the surrounding namespace. That
object lacks any export/import qualification to make it usable
with shared libraries.
Introduce therefore another macro to work around this issue, allowing
the user to prefix the object with an exporting macro, f.i. like this:
Q_NAMESPACE_EXPORT(Q_CORE_EXPORT)
The old macro can simply then be rewritten in terms of this new one,
supplying an empty export macro.
Note that NOT passing an argument to a macro expecting one is well
defined behavior in C99 -- the macro will expand an empty token.
Of course, MSVC doesn't like this and emits warnings. As a
workaround, use a variadic macro.
[ChangeLog][QtCore] Added the new Q_NAMESPACE_EXPORT macro. It
can be used just like Q_NAMESPACE to add meta-object information
to a namespace; however it also supports exporting of such
information from shared libraries.
[ChangeLog][Potentially Source-Incompatible Changes] Prefixing
Q_NAMESPACE with an export macro may no longer work. Use the new
Q_NAMESPACE_EXPORT macro for that use case.
Fixes: QTBUG-68014
Change-Id: Ib044a555ace1f77ae8e0244d824ec473550f3d8e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
The old code used the implicit conversions from QAtomicInteger<T> to T
and vice versa. The semantics of these differ from the ones std::atomic
uses, so we're going to deprecate these, like we did for load() and
store(), too.
This patch fixex some users of these APIs before we deprecate them.
Change-Id: I4877276581757cd57e042efea8296fe535a493d1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QSignalSpyCallbackSet is a set of pointers, so when we store a pointer
to it for later dereferencing, we need to use a release fence for the
store and a corresponding acquire on load, lest the two don't
synchronize with each other and we end up with a data race.
Amends a65752c71bd25bbb66bf33d3a82f7901419c5d95.
Change-Id: Ic2983d76237c5c5b00eb2a3575b10beb84d57190
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Semi-automated, just needed ~20 manual fixes:
$ find \( -iname \*.cpp -or -iname \*.h \) -exec perl -pe 's/(\.|->)load\(\)/$1loadRelaxed\(\)/g' -i \{\} +
$ find \( -iname \*.cpp -or -iname \*.h \) -exec perl -pe 's/(\.|->)store\(/$1storeRelaxed\(/g' -i \{\} +
It can be easily improved (e.g. for store check that there are no commas
after the opening parens). The most common offender is QLibrary::load,
and some code using std::atomic directly.
Change-Id: I07c38a3c8ed32c924ef4999e85c7e45cf48f0f6c
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Try to replace all wordings like '.. to 0' with '.. to \nullptr'. Also
checked for 'null pointer' and similar.
Change-Id: I73341f59ba51e0798e816a8b1a532c7c7374b74a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Use Q_TRACE_SCOPE and the corresponding naming scheme. Additionally,
don't change the behavior of the code when tracing is enabled, i.e.
continue to return early if possible.
Change-Id: I9ba9679869db1541a19bc832beede902224c52f2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change mentions of parameter value being "zero" to nullptr.
Clarify that when nullptr is passed to moveToThread() event processing
is stopped because the object is no longer associated with any thread.
Also, reitarete this fact in the paragraph about processing of new
events.
There's an exception to the rule that QObjects cannot be "pulled" by
moveToThread that is buried in the implementation and not mentioned
in the doc. This information is worth noting explicitly.
Change-Id: I816ff737c48d8057b39e36b566079710aeb8e690
Reviewed-by: André Hartmann <aha_1980@gmx.de>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This enables overriding the macro so that it translates
to 'None' in the Qt for Python context.
Change-Id: Ib3cecf57eeb0405a1929309b71e9f012a07f11cf
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
It is perfectly possible to accidentally create a parent/child
loop. This can happens by direct means (a->setParent(b);
b->setParent(a);), or some more subtle means, e.g.
class MyClass : public QObject {
MyClass() : QObject(this) {}
};
Since this is UB, add a few robustness checks to make sure the
code above crashes right away (at least in debug builds).
Change-Id: I6583c8514b4c1f8a90677b04c77b8e8f0c15dba3
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Sérgio Martins <sergio.martins@kdab.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>
Replace null and '\c nullptr' with \nullptr in the documentation.
Change-Id: Ib9e0cfc2eb2830b213e6523773603d56180b0998
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
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>
... instead of qPrintable(), %s, and explicit qt_error_string().
Saves 2KiB in text size on optimized Linux AMD64 GCC 9.1 builds.
Change-Id: I98b6717da1ed1b678f01167d704a96f10da47966
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
