Qt doesn't support VxWorks DKM since 4.8, removing DKM specific check,
so it is the same as in Qt for VxWorks 5.15.
Pick-to: 6.8
Task-number: QTBUG-136722
Change-Id: I86cf54e8eadbb78365b7c58cb72b0675714fb37a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 312215ba87b00b0065babe1cf190980e2d9dbc4a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
For the thread that calls ::exit() (usually, the main thread).
Otherwise, depending on construction order, it is possible for the
QThreadStorage's destructor list to have been destroyed by the time
destroy_current_thread_data() → QThreadData::finish() calls our
finish().
Fixes: QTBUG-135044
Pick-to: 6.8
Change-Id: Ic5a10367ff31e7faa039fffdc2067eba9642fbf9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 81a7a4c2d94fca6fc595dcb147831b9585eaee5f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
As noted in the comment, we had a chicken-and-the-egg problem with
plugins and the event dispatchers: we need to destroy the event
dispatcher when plugins are still loaded (otherwise we could and did
crash) but we also wanted the QThreadData to exist when the plugins
unload.
The solution for that is to split the work: destroy the event dispatcher
first, then unload pugins, then destroy the current thread's
QThreadData. On ELF systems, this is guaranteed to work because we set
the init_priority to call destroy_current_thread_data() to higher than
QLibraryStore. In other systems, it's a best effort with dynamic
libraries and not guaranteed at all with static builds (don't even
report bugs).
Fixes: QTBUG-134080
Fixes: QTBUG-133861
Task-number: QTBUG-132697
Task-number: QTBUG-102984
Task-number: QTBUG-132381
Pick-to: 6.9.0 6.8
Change-Id: Ifaa28bb87338f4117d51fffdf721da68c0762e5a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 6763e25cbc16cf8c54ab9b1ef97030aab9bb0eec)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
So that the pthread_key is destroyed much later than now, at QtCore
unload time instead of a bit earlier in exit(). That's important so it
runs later than the Q_DESTRUCTOR_FUNCTION for QLibraryStore
(qlibrary.cpp), which is what unloads plugins, whose unload-time
destructors may be attempting to quit() & wait() for their worker
threads.
I had to keep the destruction of the exiting thread's adopted thread
where it was: a function-local static's destructor. As noted in the
comment added by 1da7558bfd7626bcc40a214a90ae5027f32f6c7f, we need
QThreadData::cleanup() to run before the libraries start to unload
because we need to delete the event dispatcher.
Init priority 10 will place it after the QHash random seed and qsimd
initialization, on ELF systems and on Windows. On other systems (incl.
Apple ones), the order probably depends on the order of the files in the
CMakeLists.txt. I thought that would mean the destructor for thread/
would run before plugin/ but that apparently is not the case. But that's
fragile.
Amends 1da7558bfd7626bcc40a214a90ae5027f32f6c7f, which amended other
things...
Fixes: QTBUG-132697
Task-number: QTBUG-102984
Task-number: QTBUG-132381
Pick-to: 6.8
Change-Id: Id7263d6ffe7a5949cd84e35d942ad0e02df1b455
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 2f69a05bd0cd7ce63890f709ff3ed7a4f78acd70)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Amends 65093a84c2b94b1543fd4593bc45d491951d28d4, which changed how we
destroyed the main thread's QThreadData. This merges the call to
destroy_current_thread_data() for both types of Unix systems: those with
broken thread_local destructors and those with working ones. It turns
out that the function got called too early for us in those working
systems (see updated comment).
The clean up of the QThreadData is split into two different mechanisms:
* for any auxiliary thread, when it exits, PThread will call back to
destroy_current_thread_data()
* for the thread that called ::exit(), PThread won't, but ::exit() will
invoke set_thread_data()::TlsKey's destructor
This is different from the situation that existed prior to commit
65093a84c2b94b1543fd4593bc45d491951d28d4: first, there's no code in
qcoreapplication.cpp for this (all in qthread_unix.cpp). Second one may
call ::exit() from any thread, whether that is the thread that called
main(), the thread Qt thinks is theMainThread, or any other.
This commit moves the tst_QCoreApplication check for no extant objects
to a new test. I've chosen to add a new test instead of running a helper
binary via QProcess because we do have a couple of !QT_CONFIG(process)
platforms in the CI, and this is too important.
Credit to OSS-Fuzz for finding this, though it is not itself a fuzzying
problem (all tests of a given structure were crashing on exit).
Fixes: QTBUG-132381
Task-number: QTBUG-130895
Task-number: QTBUG-129927
Task-number: QTBUG-129846
Task-number: QTBUG-130341
Task-number: QTBUG-117996
Pick-to: 6.8
Change-Id: Ie294dce7263b4189f89ffffd9155ec71d31b89d9
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 1da7558bfd7626bcc40a214a90ae5027f32f6c7f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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.8
Change-Id: Iecf8f14529c7a2bb2185fffdfd328066098826b1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 357351b7ab8ab2eee865d2449ffcca9c9f502fd3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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).
Change-Id: I9682121c04fafb3676b0fffd9f5ac999e7603c84
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
(cherry picked from commit b8f84fd1e2af38ece89d60619bf93e7af34433ab)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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>
