This reverts commit c3a2b9f35a9a12ff3c6f5f0d11844de161b47c2a.
Unfortunately, some of the log messages happen WAY too late at process
exit time, when QtCore is unloading. In particular, the worst offender
is the one in QThreadPrivate::finish(), which is called after the last
QObject in the thread that called ::exit() was getting destroyed. This
implies we have Static (De)Initialization Order Fiascos happening (the
logging recurses into qlocale.cpp and the defaultLocalePrivate global
static has already been destroyed).
I need to revert this commit in order to fix QThreadData destruction.
The functionality is welcome back in QtCore once the fixes are in, so
long as whoever does it fixes the issues we're seeing in the CI (and I
can't reproduce on my development machine). I've created QTBUG-132429 to
track the reversal and see if the functionality can be brought back in.
Task-number: QTBUG-120124
Task-number: QTBUG-132429
Pick-to: 6.9 6.8
Change-Id: Iecf8f14529c7a2bb2185fffdfd328066098826b1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
It was used by the QT_TERMINATE_ON_EXCEPTION macro, introduced in 2012,
to support pre-C++11 noexcept semantics. That macro was removed for Qt
6.8 in commit 9b2ae564a59656d9cf49b141e70f5958b4fb79a4. This commit
amends that removing the definition of qTerminate() immediately in Qt
6.9 (it was an \internal function).
Pick-to: 6.9
Change-Id: I9682121c04fafb3676b0fffd9f5ac999e7603c84
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Simplying the body of the function to rely less on the exception
handling too. The implementations for Unix and Windows are now literally
identical, but duplicated because they call different static functions
Change-Id: Ia14910a1c778ff5e606afffdabb8035e4603edda
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It was duplicated in all three files. The remaining code is very
similar, but I don't think we want to merge it any further. For one
thing, we must set the thread-local variable before QAdoptedThread calls
the QObject constructor.
Change-Id: Iac9f7f7528085a1137d7fffdecf080a2b6e1aefe
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Commit 1ed0dd88a32cd2c5ae100b48e14ff55bcbb652e6 ("QThread/Unix: make
QThreadPrivate::finish() be called much later") introduced this problem.
Commit 4fabde349f16b59f37568da2a4c050c6dd53a34e split the thread
termination in two phases, but did not fix this.
This re-applies commit 950b35cf97ad398f97883efd2a18ee97994a8a9c ("Clear
the current thread data for the main thread"), which was reverted in
commit 7dc622290bb8e81af634034f443e25be0d6d48a3 ("Make sure QThreadData
and QAdoptedThread object is destroyed at app exit"), both from Qt 5.1.
Between Qt 5.1 and 6.7, the responsibility of clearing the
QAdoptedThread for the main thread was split: it could occur either in
~QCoreApplicationData if exit() was called in that thread or in
~QThreadData() if it wasn't (e.g., when the Qt "main thread" is not
main()'s thread):
* frame #0: 0x0000000101db8a28 QtCore`QAdoptedThread::~QAdoptedThread(this=0x000060000176c070) at qthread.cpp:139:1
frame #1: 0x0000000101db81eb QtCore`QThreadData::~QThreadData(this=0x0000600002468000) at qthread.cpp:82:5
frame #2: 0x0000000101db8379 QtCore`QThreadData::~QThreadData(this=0x0000600002468000) at qthread.cpp:57:1
frame #3: 0x0000000101db841c QtCore`QThreadData::deref(this=0x0000600002468000) at qthread.cpp:108:9
frame #4: 0x0000000101f4ec79 QtCore`destroy_current_thread_data(p=0x0000600002468000) at qthread_unix.cpp:104:11
This commit centralizes and gives ~QThreadData() the exclusive
responsibility. That requires not resetting QThreadData::threadId so
~QThreadData can know it is theMainThread.
Fixes: QTBUG-130895
Task-number: QTBUG-129927
Task-number: QTBUG-129846
Task-number: QTBUG-130341
Task-number: QTBUG-117996
Pick-to: 6.8
Change-Id: Ie3f3cbdc5523837b505cfffd95fba5e6498b5069
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Instead of guessing that Apple systems don't have it.
Because of this, we properly split the clockid_t constants in
qcore_unix_p.h between what the std::chrono::steady_clock uses and what
QWaitCondition will use. The difference is on Apple systems and on QNX.
Therefore, amends 5642b999754e75a9db3585b97ffbddac761f21b3.
Change-Id: Ibf5439b6cb4c332b0f24fffde43452e8ccd4e9c9
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
For some legacy reason at the time they were proposed, this extension
function is defined to operate on CLOCK_REALTIME, which is subject to
time jumps. I believe the proposal to POSIX is to implement the
clockjoin() function instead.
This commit implements support for using it if it won't make the
situation worse: that is, if QWaitCondition is already using the real-
time clock. This will enable support for Apple Darwin systems and for
QNX. The other BSDs are left out because they do have CLOCK_MONOTONIC
and pthread_condattr_setclock().
Change-Id: Ib97a7f1750cb4e3da5d1fffd68efdec02615b9ec
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This is only implemented for OSes that provide a way to perform a timed
join. For all other OSes, we stick to the previous implementation, which
as the comment indicates, may run for arbitrarily long time after wait()
has returned, running user code (e.g., pthread_setspecific() and
thread_local destructors).
Instead, if we perform the joining, we are assured by pthread and the OS
that the thread has exited and no user code remains running.
Unfortunately, this only applies to non-adopted threads, because we
can't pthread_join() a thread we didn't start.
As of this writing, this code only applies to Linux/glibc. MUSL, Bionic
and several BSDs have pthread_timedjoin, but that takes a CLOCK_REALTIME
absolute time, which means it's subject to time jumps, while
QWaitCondition can sometimes use the monotonic clock in those systems.
Change-Id: I692e24d7411742447e10fffd650fe84f6a9cdedd
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
With heterogenous CPU topology (and earlier, per-core clocks) OS
developers have increasingly added "Quality of Service" APIs to thread
scheduling, giving users a way to tell the OS what type of work the
thread is expected to do.
In the case of Apple they have a more extensive selection of
service levels. Unlike what we currently see from Windows, the API there
is actually much broader than just High, 'Default' and Eco, and covers
more concrete uses like "Utility", "Background", "User-initiated",
defined as -1 (Default), and a range from 0x09 (Background)
to 0x21 (User-interactive)[0].
Currently there is no equivalent API for Linux though there is some push
from various interested parties to add one (e.g. [1]).
As mentioned, on Windows there is really only 3 levels, though it's
defined as "do/don't throttle this thread" and "do as you wish".
For Android I cannot really find anything equivalent beyond the thread
priority.
Discussed here:
https://lists.qt-project.org/pipermail/development/2024-September/045694.html
[0] https://developer.apple.com/documentation/foundation/qualityofservice
[1] https://www.youtube.com/watch?v=RfgPWpTwTQo (Linux Plumbers Conference)
Fixes: QTBUG-93946
Change-Id: Iabeaa7b61cec0bebd5c6a4bcf75a8e60dc0348dc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This code predated the existence of the currentThreadId() and
isCurrentThread() functions. Our implementations are slightly faster.
Pick-to: 6.8
Change-Id: Id2b20a7f06e0c2a1bc35fffd4fb4dcf3f20769cd
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This is a corner-case scenario but valid because we tell users they can
destroy the QThread object right after finished() has been emitted. But
emitting finished() does not mean the launched thread has actually
exited: it may still be in Finishing state for an arbitrarily long time.
Completely aside from what else may run from other libraries, we only
destroy QThreadStorage and the thread's event dispatcher after
finished() has been emitted.
This commit avoids the unnecessary mutex unlocking in the destructor,
then QThread::wait() locking again, only to unlock yet again so that it
can perform the necessary low-level wait calls. The same for the return
path: wait() locked again to check the state, then unlocked, only for
the destructor to lock again. Now, QThreadPrivate::wait() is responsible
for returning with a locked mutex.
Pick-to: 6.8
Change-Id: I87adffb89f275accea18fffd6b4293861ea7cf39
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Removing unused headers and sorting them in the standard "mine", "Qt's"
and "other" order. Sorted by file name, not complete path.
Change-Id: I6cbcdb5887175bdd7618fffd0627222ff4718efc
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Commit 1ed0dd88a32cd2c5ae100b48e14ff55bcbb652e6 moved the finish()
functionality from immediately after run() returns to the time of
thread-local destruction, to make sure that user destructors didn't run
after our cleaning up. But as a side effect, it made other user code run
too late, after some thread-local statics had been destroyed.
This is a common practice, which causes the destructor for worker to run
too late:
worker->moveToThread(thread);
...
QObject::connect(thread, &QThread::finished, thread, &QObject::deleteLater);
QObject::connect(thread, &QThread::finished, worker, &QObject::deleteLater);
This commit splits the cleanup in two phases: QThreadPrivate::finish(),
which runs immediately after run() and will call back out to user code
(finished() signal and delivery of deleteLater()), and cleanup() that
cleans up the QThread{Private,Data} state and destroys the event
dispatcher. That destruction is the only call out to user code.
I've removed the complex mix of pre-C++11 pthread_setspecific() content
and C++11 thread_local variables in favor of using one or the other, not
both. We prefer the thread-local for future-proofing and simplicity, on
platforms where we can verify this C++11 feature works, and because it
allows us to clean up QThreadData and the event dispatcher as late as
possible. (There's some code that runs even later, such as pthread TLS
destructors, used by Glib's GMainLoop)
Unfortunately, we can't use it everywhere. The commit above had already
noticed QNX has a problem and recent bug reports have shown other
platforms (Solaris, MUSL libc) that, 13 years after the ratification of
the standard, still have broken support, so we use pthread for them and
we call cleanup() from within finish() (that is, no late cleaning-up,
retaining the status quo from Qt 4 and 5). See QTBUG-129846 for an
analysis.
Drive-by moving the resetting of thread priority to after finished() is
emitted.
[ChangeLog][QtCore][QThread] Restored the Qt 6.7 timing of when the
finished() signal is emitted relative to the destruction of thread_local
variables. Qt 6.8.0 contained a change that moved this signal to a later
time on most Unix systems, which has caused problems with the order in
which those variables were accessed. The destruction of the event
dispatcher is kept at this late stage, wherever possible.
Fixes: QTBUG-129927
Fixes: QTBUG-129846
Fixes: QTBUG-130341
Task-number: QTBUG-117996
Pick-to: 6.8
Change-Id: Ie5e40dd18faa05d8f777fffdf7dc30fc4fe0c7e9
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The implicit load is an acquire, which isn't necessary in any of these
cases, including the two liens changing the store: they were creating a
temporary QAtomicPointer, which introduced the loadAcquire().
I've left the qCDebug() lines alone.
Pick-to: 6.8 6.5
Change-Id: If45e068eaaf3cd4d2c81fffd1459a779b4eb4110
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Posix doesn't seem to specify whether the stack of cancelled threads
is unwound, and there's nothing preventing a QThread from
terminate()ing itself, so be extra careful to drop the mutex before
calling pthread_cancel.
We can't drop the mutex in general, as that would open a window for
the following race condition:
T1 T2
t3->terminate()
lock();
read ID;
terminated = true;
unlock();
----------- t3 exits naturally -----------
t3->wait();
t4->start(); // gets ex-t3's ID
pthread_cancel(ID) // oops, cancels new t4
But we can drop it when this == currentThread(), because said window
does not exist: While this_thread is executing terminate(), it cannot
at the same time exit naturally.
As drive-by, scope a variable tighter.
Pick-to: 6.8 6.7 6.5
Change-Id: I77a628e62d88e383d5aa91cfd97440186c997fc4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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.8 6.7 6.5 6.2 5.15
Change-Id: Iec180bdfaaf913a3a1560210c781966dc99c0d42
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
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
Pick-to: 6.8
Change-Id: I23030eefdfcebf0a6d6796db5cbbbf0812ae12c0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There aren't 2^3 possible states for {running, isInFinish, finished}.
There are only three possible states for them.
There's a fourth case of NotStarted, which in my opinion is a design
flaw. It needs to exist so QThread().isFinished() is false, but in a
green field design we would be the same as QProcess: once a process/
thread finishes, it goes back to NotRunning.
I also made the Windows version set back to NotStarted when failing to
start, matching the Unix version.
Drive-by use NSDMI.
Change-Id: I262c3499666e4f4fbcfbfffd17cb3a48dad045dc
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It can be hard to distinguish QThreads without object names when
debugging.
Pick-to: 6.8
Change-Id: I42643495344063b7c05c7639dcc15c6600e617dc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
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>
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>
