QThread::terminate() is documented to be thread-safe, but had a race
condition: If multiple threads call terminate() on the same thread,
the following could happen:
T1 T2
t0->terminate();
lock();
read ID;
pthread_cancel(ID);
unlock()
t0->terminate();
lock();
read ID;
(OS thread finishes)
t3->start();
(creates a new OS
thread with same ID)
pthread_cancel(ID); // cancels new t3!
unlock();
To fix, record that the thread was already terminated using a new
boolean flag.
An alternative would have been to fetchAndSet() the threadId to nullptr
and only let the thread that actually nulled it call pthread_cancel(),
but that would be harder to restore to the previous state in case
pthread_cancel() fails, and a null threadId might cause other problems
down the line, esp. if cancellation is currently disabled. The
explicit state is much simpler to reason about.
Fixes: QTBUG-127055
Pick-to: 6.7 6.5 6.2 5.15
Change-Id: Iec180bdfaaf913a3a1560210c781966dc99c0d42
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit d8bd4c2306f2acfefc75f8163b58f2037596dc65)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The QThreadPrivate::finish() cleanup code is not prepared to be
subjected to POSIX cancellation: if, like on glibc, thread
cancellation is implemented by stack ununwinding, we get exceptions in
dtors and therefore std::terminate(), and otherwise, we leak
resources.
It would be very hard to make the code robust against this, as it
would require all cleanup to be wrapped in pthread_cleanup_push/pop,
with the added problem that these functions need to appear in the same
lexical scope. Another alternative would be to move all cleanup code
into a thread_local destructor, but it's not clear whether code
running as part of thread_local destruction would be exempt from
cancellation, and it would be a major rewrite.
The simplest method is to disable cancellation for the remainder of
the thread lifetime in the shutdown code, just like the startup code
only enables cancellation after initial setup, so do that.
[ChangeLog][Important Behavior Changes][QThread] On Unix,
fixed a race of QThread::terminate() with normal thread exit (running
off the end of run()) which could corrupt QThread's internal cleanup
code. The fix involves disabling thread cancellation for the remainder
of the thread's lifetime once control reaches QThread's cleanup
code. If you rely on a PTHREAD_CANCELED return status, be aware that
this change may mask late cancellations. Likewise, slots connected to
QThread::finished() using Qt::DirectConnection are now run in a regime
where thread cancellation is already disabled. If you need
cancellation in that situation to work, you need to define your own
finished()-like signal and emit that at the end of run().
Fixes: QTBUG-127008
Change-Id: I23030eefdfcebf0a6d6796db5cbbbf0812ae12c0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 01d4be4a8327458a3242804594b498f840480289)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It can be hard to distinguish QThreads without object names when
debugging.
Change-Id: I42643495344063b7c05c7639dcc15c6600e617dc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit ba13bbd2d32652c8ffeef691c9a2ed3a7a65a82f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
1. VxWorks 6.* and older are not supported in Qt6 due to C++17
requirement (among multiple other issues).
2. `_WRS_VXWORKS_MAJOR` and `_WRS_VXWORKS_MINOR` are defined in header
`version.h` on VxWorks 7, which is not included anywhere, causing
`QThread::idealThreadCount()` to always return 1. As a consequence,
instance of `QThreadPool` returned by `QThreadPool::globalInstance()`
have always only 1 thread. This causes failure of
`tst_QEventDispatcher::postEventFromThread` test case.
To fix that, remove VxWorks version checking from qthread_unix.cpp.
Pick-to: 6.7
Task-number: QTBUG-115777
Change-Id: I08ffc4acdb74d13dd822402407a71f5916603440
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 8fec93e9a7bf3f8cb80aafb1e2329d998552fbcc)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
On VxWorks, its pthread implementation fails on call to
`pthead_setspecific` which is made by first `QObject` constructor during
`QThreadPrivate::finish()`. This causes call to `QThreadData::current`,
since `QObject` doesn't have parent, and since the pthread is already
removed, it tries to set `QThreadData` for current pthread key, which
crashes.
The aforementioned `QObject`'s instances are created in multiple places
during `QThreadPrivate::finish` method, first one in during call to
`qCDebug()`.
The sequence currently leading to call to `QThreadData::current` starts
with `qCDebug` call in `QThreadPrivate::finish`, which:
- creates `QDebug` object, which
- creates `Stream`, which
- creates `QTextStream`, which
- creates `QTextStreamPrivate`, which
- creates `QDeviceClosedNotifier`, which
- is a `QObject`, which
- calls `QThreadData::current()` because its `parent` is nullptr.
Even ignoring debug print, next line calls
`QCoreApplication::sendPostedEvents` which calls `QThreadData::current`
directly.
Pick-to: 6.7
Task-number: QTBUG-115777
Change-Id: I4d405eebdff0c63c6cd66fba4eaa95c3818ceaea
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We need it to run after all the thread-local destructors have run, to
ensure that some user code hasn't run after QThreadPrivate::finish() has
finished. We achieve that by making it get called from a thread-local
destructor itself, in the form of a qScopeGuard.
This ought to have been done since C++11 thread_local with non-trivial
destructors became available. However, it only started showing up after
commit 4a93285b166ceceaea2e10c8fc6a254d2f7093b9 began using thread_local
inside Qt itself. The visible symptom was that QThreadPrivate::finish()
had already destroyed the thread's event dispatcher, but some user code
ran later and expected it to still exist (or, worse, recreated it, via
QEventLoop → QThreadData::ensureEventDispatcher).
Fixes: QTBUG-117996
Pick-to: 6.7
Change-Id: I8f3ce163ccc5408cac39fffd178d682e5bfa6955
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Useful for QtCreator, as a replacement for
Utils::isMainThread() inside threadutils.h,
may serve for other projects, too.
Introduce static QCoreApplicationPrivate::theMainThreadId
atomic helper field holding the id of the main thread.
Change-Id: Iccc0302f423f47b5ecad86c4cd3de4d1ee36155f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A QT_MESSAGE_PATTERN including %{backtrace depth=4} should give
the call site of the QScopedScopeLevelCounter.
Task-number: QTBUG-120124
Change-Id: Ie477994882bde9168c931479102017ad5fde426a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This non-namespaced macro was defined in a header, and while that
header is private, we shouldn't define non-namespaced macros in our
headers.
The macro also clashed with one of the same name defined in forkfd.c,
which broke unity-builds including the forkfd_qt.cpp TU. This rename
fixes that, too, so we can now remove forkfd_qt.cpp from
NO_UNITY_BUILD_SOURCES.
Pick-to: 6.6 6.5
Change-Id: Ic4bb4e4d7a632ca87905e48913db788a7c202314
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Instead, check the macro that we're about to use. This is also done in
qprocess_unix.cpp
Pick-to: 6.5 6.6
Change-Id: I8f3ce163ccc5408cac39fffd178d657b7594d07a
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Unix dispatcher is not used and - as such - redundant on WASM.
Change-Id: Ia8789ef783b06ce9cfba2ce9d67159db2355b594
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
I got tired of being told off by the inanity 'bot for faithfully
reflecting existing #if-ery in new #if-ery. Retain only the
documentation and definition of the deprecated define.
Change-Id: I47f47b76bd239a360f27ae5afe593dfad8746538
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
All the other overloads are implemented using the new one.
Windows change relies on the pre-check in the code review making sure it
compiles.
[ChangeLog][QtCore][QThread] Added sleep(std::chrono::nanoseconds)
overload.
Task-number: QTBUG-110059
Change-Id: I9a4f4bf09041788ec9275093b6b8d0386521e286
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's the only place that uses it.
Pick-to: 6.5
Change-Id: Ieec322d73c1e40ad95c8fffd17465370ac209c2f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
They offer no value over the traits in the standard library (in fact,
they're implemented precisely in terms of those traits).
This commit is done in preparation for their removal.
Change-Id: I3fb67e03e1c476f6ac0b369dfbbcf46b291270c8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Fix possible undefined behavior in clear_thread_data.
The key used in pthread_setspecific must be obtained
from pthread_key_create or undefined behavior occurs.
Use set_thread_data to clear it since it ensures that
the key has been obtained using pthread_key_create
by calling pthread_once using
create_current_thread_data_key.
Fixes crash when closing threaded qt apps on NetBSD.
Pick-to: 5.15 6.2 6.3 6.4
Change-Id: I1c7d2628f4248e00a12724a952568f7d92011986
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Still not complete. Just grepping for static and thread_local.
Task-number: QTBUG-100486
Change-Id: I90ca14e8db3a95590ecde5f89924cf6fcc9755a3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This works around mismatch in threads starting and restarting QThreads,
and is safe since we don't need to establish a binding, and objectName
access in QThreadPool is locked behind a mutex.
Pick-to: 6.3 6.2
Fixes: QTBUG-96718
Change-Id: Id3f75e4f8344796ca658899645219fe3373ddd6d
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This is a data race, as the thread accesses QObject::objectName on the
QThread instance while the thread owning the QThread might modify the
objectName.
Instead, make a copy in the QThreadPrivate that can be accessed safely.
Task-number: QTBUG-96718
Pick-to: 6.3 6.2 5.15
Change-Id: I10701551d498993ca5055daf161636bfb648840c
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The Unix code stores an additional flag, ThreadPriorityResetFlag, in
the Policy enum, but ubsan does not approve:
qthread_unix.cpp:303:30: runtime error: load of value 2147483648, which is not a valid value for type 'Priority'
qthread_unix.cpp:304:75: runtime error: load of value 2147483648, which is not a valid value for type 'Priority'
Fix by making the variable of std::underlying_type_t<Priority>.
The masking and unmasking code can now be simplified, too.
In the Windows version, replace some switch targets with equivalent
ones to keep -Wswitch-like warnings, though I hasten to note that both
switches use a default case, so have anyway implicitly disabled said
warning.
Pick-to: 6.3 6.2 5.15
Change-Id: Ie4ea7d05e2928d2755ad12d36535197f85493191
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Extract function terminate_on_exception() that de-duplicates the
#ifdef'ery around the try/catch and the handling of the pthread
cancellation pseudo-exception.
Apart from de-duplicating complex code, it will also help suppressing
a ubsan false positive, which is why we're picking it all the way to
5.15.
Pick-to: 6.3 6.2 5.15
Change-Id: I99ad2c0618b8dc30801931df09400c6611d9f9e4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Instead of returning the total number of logical processors in the
system, which we may not be allowed to wholly run on, use the affinity
set that the calling thread is allowed to use.
Implemented for Linux and FreeBSD only, with up to 4x the number of
processors than CPU_SETSIZE has as default (that would be 4096 logical
processors on Linux, 1024 on FreeBSD). Implementation for Windows is
possible, but the API there is always limited to 64, so I'm unsure if it
is correct. Darwin (macOS) does not have this capability.
Testing:
$ ./tst_qthread idealThreadCount | grep QDEBUG
QDEBUG : tst_QThread::idealThreadCount() Ideal thread count: 8
$ taskset 3 ./tst_qthread idealThreadCount | grep QDEBUG
QDEBUG : tst_QThread::idealThreadCount() Ideal thread count: 2
[ChangeLog][QtCore][QThread] idealThreadCount() will now return the
number of logical processors that the current process (thread) has
assigned in its affinity set, instead of the total number of processors
in the system. These two numbers can be different if the process is
launched by the parent with a different affinity set, with tools like
Linux's taskset(1) or schedtool(1). This is currently implemented for
Linux and FreeBSD.
Change-Id: I2cffe62afda945079b63fffd16bd086f64f5f314
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Unix QThread implementation stores pthread_t as a system thread ID
when the thread is created, but never resets the system ID when
those threads are destroyed. Some implementations may reuse the
same thread IDs for new threads, and this may cause QThread::wait()
to erroneously complain that "Thread tried to wait on itself".
This patch sets the system thread ID to nullptr when the thread is
about to exit and be destroyed by the system.
A regression test is added to tst_qthread.
Fixes: QTBUG-96846
Pick-to: 5.15 6.2
Change-Id: I0850425dd0e09af50e59c9038e7e662a2a624beb
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The thread ID is already initialized inside QThread::start() while
the thread lock is taken. This is completed before the attempted
initialization in QThreadPrivate::start() because it tries to take
the same lock.
Task-number: QTBUG-96846
Pick-to: 5.15 6.2
Change-Id: Ic9588f3e2e2f3c2180afbed8ec01155b33043eb3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use the new event dispatcher for all non-GUI threads,
nn practice for the main thread when using QCoreApplication,
and when calling QThread::exec().
Change-Id: I9184d52532e06da7e6a87ee27c7d53e0d15e693a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
...instead of during createEventDispatcher().
This way, startingUp() will be called [on the thread
being started] also for custom event dispatchers installed
with QThread::setEventDispatcher().
This prevents crashes when installing event dispatches which
expects that startingUp() will be called.
Crash reproducible with test case from QTBUG-51961.
Change-Id: I71bd696539689d928a61ff9b47d05297cf803b2f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is required to remove the ; from the macro with Qt 6.
Task-number: QTBUG-82978
Change-Id: I3f0b6717956ca8fa486bed9817b89dfa19f5e0e1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Amends dcdfb6908db0f83cbc4e550859f56ee58a6b3420 which failed to take the
workaround in destroy_current_thread_data into account.
Since pthread_getspecific was completely replaced with the thread_local variable
currentThreadData, the workaround has no effect anymore. Therefore we need to
replace it with a workaround that makes sure currentThreadData is set inside of
the destructor function.
This prevents a leak, where QThreadPrivate::finish() tries to access the
thread data, but since it already is null, recreates it without ever deleting it.
Pick-to: 5.15
Change-Id: I3811d262a411a6bde9d6eb90f8d17e0bbc5de657
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The change introduced crashes in some tests that only surfaced
in certain CMake configurations.
This reverts commit 76c3eee4020cae681857ee17406c655f61f9082c.
Pick-to: 5.15
Task-number: QTBUG-85357
Change-Id: Ief93aa41e2d487d73b879133e7df0fd5ce0451bd
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The thread specific QThreadData is currently referenced as a thread_local
variable and using a thread specific value via pthread_setspecific.
Having both is not necessary, as the pthread value is never directly accessed
and only used in the pthread destructor. Using a holder, we can achieve the same
and get rid of the pthread handling altogether.
This also fixes a bug, where the thread_local currentThreadData is already null,
when entering the pthread destructor. In this case it would lead to a new QThreadData
being created, when finishing an adopted thread.
Pick-to: 5.15
Change-Id: Ib23b840f804637e6b7cebd89016672a34a575380
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There is no reason for keep using our macro now that we have C++17.
The macro itself is left in for the moment being, as well as its
detection logic, because it's needed for C code (not everything
supports C11 yet). A few more cleanups will arrive in the next few
patches.
Note that this is a mere search/replace; some places were using
double braces to work around the presence of commas in a macro, no
attempt has been done to fix those.
tst_qglobal had just some minor changes to keep testing the macro.
Change-Id: I1c1c397d9f3e63db3338842bf350c9069ea57639
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
If the assembler code cannot be used to retrieve the threadId, always
use pthread_self() for it. QObject uses QThread::currentThreadId() and
QThreadData::threadId to match threads, which makes address of the
currentThreadData unsuitable as the thread id.
Reading the threadId from currentThreadData is slower than calling
pthread_self(), as tested on Aarch64 linux and x86_64 QNX.
Change-Id: If9afc8ed2810ad1e04bd42ead8f40b43ef3bac30
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Move away from using 0 as pointer literal.
Done using clang-tidy. This is not complete as
run-clang-tidy can't handle all of qtbase in one go.
Change-Id: I1076a21f32aac0dab078af6f175f7508145eece0
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
So we are in sync with QWaitCondition::wait().
Task-number: QTBUG-64266
Change-Id: I1d7487786513241cedd35d202c4ddee4937b08ec
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Mark QWaitCondition:wait(..., ulong) as deprecated so they can be
removed in Qt6. Also replace the usages of this deprecated functions
inside QtCore.
Change-Id: I77313255fa05f5c112b0b40d4c55339cc4f85346
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is, depending on the implementation of pthread, significantly
cheaper than using a pthread library call.
Even if we don't know the assembler for an architecture, taking
the address of the thread_local variable is still faster.
As QThread::currentThreadId() is documented to be used internally
and not meant for application code, we don't have to care about
what exact value we return. Internally, we use it only to compare
thread IDs for equality, which this implementation is sufficient
for, even if a thread ID is re-used when one of the threads
terminate and a new thread starts (since the other thread is still
executing code). Besides, pthread_self documents [0] that a thread
ID may be reused, and that the returned pthread_t cannot be
portably compared using operator==(); using pthread_equal would
require adding a Qt thread-ID type that implements this correctly,
and would make things even slower.
[0] http://man7.org/linux/man-pages/man3/pthread_self.3.html
Change-Id: Id08e79b9b9c88976561f7cd36c66d43771fc4f24
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
With C++11, all compilers support thread_local, which replaces the non-
standardized __thread attribute as a storage class.
The storage class was specifically introduced so that applications do
not have to deal with pthread APIs for TLS key management. We still
need to have some of that logic for adopting foreign threads, but we
can rely on thread_local so that we get a fast implementation of
QThread::currentThread() on all platforms.
Change-Id: Iba2b35d014044c4ab317a0e127c5d1f1fa4ecd4a
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
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>
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>
