Amends dcdfb6908d 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 76c3eee402.
Pick-to: 5.15
Task-number: QTBUG-85357
Change-Id: Ief93aa41e2d487d73b879133e7df0fd5ce0451bd
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Omitting state machine and docs for now.
Task-number: QTBUG-84469
Change-Id: Ibfa5e7035515773461f6cdbff35299315ef65737
Reviewed-by: Sona Kurazyan <sona.kurazyan@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>
Commit ec6556a2b9 changed the member from
a plain pointer to a QAtomicPointer. Not all accesses were caught.
Pick-to: 5.15
Change-Id: I3d4f433ff6e94fd390a9fffd161b4ff25508c48d
Reviewed-by: David Faure <david.faure@kdab.com>
Applied to headers only. Source file to be changed separately.
Omitted statemachine for now to avoid conflicts.
Omitted qmetatype.h for now - to be handled later.
Task-number: QTBUG-84469
Change-Id: I317376037a62467c313467d92955ad0b7473aa97
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
QThreadPool is a QObject and must be deleted if the QCoreApplication
is being destroyed to release the underlying ThreadData.
A Q_GLOBAL_STATIC won't release any memory is not able to
manually release it.
Pick-to: 5.15
Task-number: QTBUG-84234
Change-Id: Ia82bcff2b564b753ed687f025ff86fa1bed1e64c
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>
Documented QPromise. Added snippets under auto tests
to ensure they are compiled and run in CI.
Task-number: QTBUG-81586
Change-Id: I20084e38f9d2f6fc8540f95ee03ec3d2827177e8
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
QPromise and QFuture created from it share the same internal state
(namely, QFutureInterface object). QPromise provides high-level
management of the shared resource, ensuring thread-safe behavior
on construction and destruction (also taking into account
QFuture::waitForFinished() semantics).
QFuture acts as a primary controller of QPromise via action
initiating methods such as suspend() or cancel(). QPromise is
equipped with methods to check the status, but the actual
handling of QFuture action "requests" is user-defined.
[ChangeLog][QtCore][QPromise] Added QPromise class to accompany
QFuture. It allows one to communicate computation results and
progress to the QFuture via a shared state.
Task-number: QTBUG-81586
Change-Id: Ibab9681d35fe63754bf394ad0e7923e2683e2457
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Macros and the await helper function from qfunctions_winrt(_p).h are
needed in other Qt modules which use UWP APIs on desktop windows.
Task-number: QTBUG-84434
Change-Id: Ice09c11436ad151c17bdccd2c7defadd08c13925
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Deprecated the pause-related APIs of QFuture* classes and
added alternatives having "suspend" in the name instead.
With 2f15927f01 new
isSuspended()/suspended() APIs have been added to QFuture* classes for
checking if pause/suspension is still in progress or it already took
effect. To keep the naming more consistent, renamed:
- setPaused() -> setSuspended()
- pause() -> suspend()
- togglePaused() -> toggleSuspended()
- QFutureWatcher::paused() -> QFutureWatcher::suspending()
Note that QFuture*::isPaused() now corresponds to (isSuspending() ||
isSuspended()).
[ChangeLog][Deprecation Notice] Deprecated pause-related APIs of
QFuture and QFutureWatcher. Added alternatives having "suspend" in
the name instead.
Change-Id: Ibeb75017a118401d64d18b72fb95d78e28c4661c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
This can lead to a deadlock if we block all the worker threads, waiting
for the worker threads to finish.
Pick-to: 5.15
Fixes: QTBUG-84619
Change-Id: I92b7f96007897d86ece0c34223bab0df4ccbed9a
Reviewed-by: Sona Kurazyan <sona.kurazyan@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>
Because setting QFutureInterface to paused state does not mean that
the computations that are already in progress will stop immediately,
it may be useful to get notified when pause actually takes effect.
Introduced the QFutureWatcher::suspended() signal, to be emitted when
there are no more computations in progress, and no more result ready
or progress reporting signals will be emitted, i.e. when pause took
effect. Added {QFuture, QFutureWatcher}::isSuspended() methods for
checking if pause took effect.
QtConcurrent will now to send QFutureCallOutEvent::Suspended event
when the state is paused and there are no more active threads.
[ChangeLog][QtCore][QFutureWatcher] Added a new QFutureWatcher::suspended()
signal, to be emitted when pause took effect, meaning that there are no
more computations in progress. Added {QFuture, QFutureWatcher}::isSuspended()
methods for checking if pause took effect.
Fixes: QTBUG-12152
Change-Id: I88f2ad24d800cd6293dec63977d45bd35f9a09f0
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
When QFutureWatcher (or QFutureInterface) is paused, it doesn't
mean that it will take effect immediately: the pending tasks may
still be in progress and keep reporting results. At the moment
QFutureWatcher will queue those events and report only with the
next resume. This behavior is wrong, QFutureWatcher should not
decide when to report events, the sender should decide when is the
right time. There's no benefit in reporting already happened events
with delay. Because of this, even the pause event itself was being
reported after resume.
Fixed the behavior by removing the logic of queueing events when
the state is set to "paused". It seems unlikely that the users of
QFutureWatcher rely on reporting events with delay.
[ChangeLog][Important Behavior Changes][QtCore] QFutureWatcher will not
immediately stop delivering progress and result ready signals when the
future is paused. At the moment of pausing there may be still computations
that are in progress and cannot be stopped. Signals for such computations
will be still delivered after pause, instead of being postponed and
reported only after next resume.
Fixes: QTBUG-12152
Change-Id: I9f0b545ac096578c52cc72d60575c018c01e3368
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Added QFuture::onCanceled() method, for attaching handlers to be called
when the QFuture gets canceled.
Change-Id: I1f01647d6173ba0c1db6641e14140108b33ac7c4
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Introduced QtFuture::connect(sender, signal) function returning a
QFuture object, which is resolved when the signal is emitted.
Task-number: QTBUG-81589
Change-Id: Idbe301eb247b468b9b34f3470c3359d6a7af2f3a
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The reference counter could only ever be -1, 0 or 1,
as an autoDeleted QRunnable can only be in a single
thread pool.
This commits keeps the reference counting for now,
but asserts sanity, simplifies locking and fixes a
leak.
Pick-To: 5.15
Fixes: QTBUG-20251
Fixes: QTBUG-65486
Change-Id: I4de44e9a4e3710225971d1eab8f2e332513f75ad
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Added asserts to insure the invariant declared in the documentation.
Canceled future object is not valid, hence we don't need to handle
this case separately.
Fixes: QTBUG-83389
Change-Id: Ib0653ef40cd3135574a91740e4ce2c6dc4da8a71
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Use the move-only versions of result reporting and getting operations,
if the type of QFuture is not copyable.
Task-number: QTBUG-81941
Change-Id: Ic9fa978380e2c24e190e68d974051a650b0e5571
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
Also fixed a few unrelated typos in docs.
Task-number: QTBUG-83236
Change-Id: I776cda8f0ef4de6c4a93e94092dc19e94d1884c8
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Conflicts:
examples/opengl/doc/src/cube.qdoc
src/corelib/global/qlibraryinfo.cpp
src/corelib/text/qbytearray_p.h
src/corelib/text/qlocale_data_p.h
src/corelib/time/qhijricalendar_data_p.h
src/corelib/time/qjalalicalendar_data_p.h
src/corelib/time/qromancalendar_data_p.h
src/network/ssl/qsslcertificate.h
src/widgets/doc/src/graphicsview.qdoc
src/widgets/widgets/qcombobox.cpp
src/widgets/widgets/qcombobox.h
tests/auto/corelib/tools/qscopeguard/tst_qscopeguard.cpp
tests/auto/widgets/widgets/qcombobox/tst_qcombobox.cpp
tests/benchmarks/corelib/io/qdiriterator/qdiriterator.pro
tests/manual/diaglib/debugproxystyle.cpp
tests/manual/diaglib/qwidgetdump.cpp
tests/manual/diaglib/qwindowdump.cpp
tests/manual/diaglib/textdump.cpp
util/locale_database/cldr2qlocalexml.py
util/locale_database/qlocalexml.py
util/locale_database/qlocalexml2cpp.py
Resolution of util/locale_database/ are based on:
https://codereview.qt-project.org/c/qt/qtbase/+/294250
and src/corelib/{text,time}/*_data_p.h were then regenerated by
running those scripts.
Updated CMakeLists.txt in each of
tests/auto/corelib/serialization/qcborstreamreader/
tests/auto/corelib/serialization/qcborvalue/
tests/auto/gui/kernel/
and generated new ones in each of
tests/auto/gui/kernel/qaddpostroutine/
tests/auto/gui/kernel/qhighdpiscaling/
tests/libfuzzer/corelib/text/qregularexpression/optimize/
tests/libfuzzer/gui/painting/qcolorspace/fromiccprofile/
tests/libfuzzer/gui/text/qtextdocument/sethtml/
tests/libfuzzer/gui/text/qtextdocument/setmarkdown/
tests/libfuzzer/gui/text/qtextlayout/beginlayout/
by running util/cmake/pro2cmake.py on their changed .pro files.
Changed target name in
tests/auto/gui/kernel/qaction/qaction.pro
tests/auto/gui/kernel/qaction/qactiongroup.pro
tests/auto/gui/kernel/qshortcut/qshortcut.pro
to ensure unique target names for CMake
Changed tst_QComboBox::currentIndex to not test the
currentIndexChanged(QString), as that one does not exist in Qt 6
anymore.
Change-Id: I9a85705484855ae1dc874a81f49d27a50b0dcff7
The no-thread build is not maintaining the
QThreadData refcount.
Change-Id: I80ce4151b8da9391764ed3d820943dcac0d70999
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Added QFuture::onFailed() method, which allows attaching handlers for
exceptions that may occur in QFuture continuation chains.
Task-number: QTBUG-81588
Change-Id: Iadeee99e3a7573207f6ca9f650ff9f7b6faa2cf7
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Replaced the internal ExceptionHolder for storing QException* by
std::exception_ptr. This will allow to report and store exceptions
of types that are not derived from QException.
Task-number: QTBUG-81588
Change-Id: I96be919d8289448b3e608310e51a16cebc586301
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
QFuture's original design pre-dates C++11 and its
introduction of move semantics. QFuture is documented
as requiring copy-constructible classes and uses copy
operations for results (which in Qt's universe in general
is relatively cheap, due to the use of COW/data sharing).
QFuture::result(), QFuture::results(), QFuture::resultAt()
return copies. Now that the year is 2020, it makes some
sense to add support for move semantics and, in particular,
move-only types, like std::unique_ptr (that cannot be
obtained from QFuture using result etc.). Taking a result
or results from a QFuture renders it invalid. This patch
adds QFuture<T>::takeResults(), takeResult() and isValid().
'Taking' functions are 'enabled_if' for non-void types only
to improve the compiler's diagnostic (which would otherwise
spit some semi-articulate diagnostic).
As a bonus a bug was found in the pre-existing code (after
initially copy and pasted into the new function) - the one
where we incorrectly report ready results in (rather obscure)
filter mode.
Fixes: QTBUG-81941
Fixes: QTBUG-83182
Change-Id: I8ccdfc50aa310a3a79eef2cdc55f5ea210f889c3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QFuture<void> and QFutureWatcher<void> are specialized to not contain
any of result fetching methods, but otherwise they share almost the same
implementation with QFuture<T> and QFutureWatcher<T> respectively.
This change unifies their implementations to get rid of unnecessary code
duplication.
Change-Id: I9494ddc58c6db192c66edb988105927da6d61a3b
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
Also documents the ownership of the traditional tryStart better, and
remove a redundant check.
Change-Id: I06202465b782926724fa33a901d08c1626f87373
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Added QFuture::then() methods to allow chaining multiple asynchronous
computations.
Continuations can use the following execution policies:
* QtFuture::Launch::Sync - the continuation will be launched in the same
thread in which the parent has been executing.
* QtFuture::Launch::Async - the continuation will be launched in a new
thread.
* QtFuture::Launch::Inherit - the continuation will inherit the launch
policy of the parent, or its thread pool (if it was using a custom one).
* Additionally then() also accepts a custom QThreadPool* instance.
Note, that if the parent future gets canceled, its continuation(s) will
be also canceled.
If the parent throws an exception, it will be propagated to the
continuation's future, unless it is caught inside the continuation
(if it has a QFuture arg).
Some example usages:
QFuture<int> future = ...;
future.then([](int res1){ ... }).then([](int res2){ ... })...
QFuture<int> future = ...;
future.then([](QFuture<int> fut1){ /* do something with fut1 */ })...
In the examples above all continuations will run in the same thread as
future.
QFuture<int> future = ...;
future.then(QtFuture::Launch::Async, [](int res1){ ... })
.then([](int res2){ ... })..
In this example the continuations will run in a new thread (but on the
same one).
QThreadPool pool;
QFuture<int> future = ...;
future.then(&pool, [](int res1){ ... })
.then([](int res2){ ... })..
In this example the continuations will run in the given thread pool.
[ChangeLog][QtCore] Added support for attaching continuations to QFuture.
Task-number: QTBUG-81587
Change-Id: I5b2e176694f7ae8ce00404aca725e9a170818955
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Less \a fun though.
Note using references in this API would just duplicate the API, but
still end up with a copy when creating the QRunnable. By having the
copy apparent directly in the API, we not only save the duplication,
we also hint to the caller to use move if they want to avoid a copy.
Change-Id: If11476d4b38853839c1e87e0339807a1798fc875
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- QCborError: Classes cannot relate to header files; use \inheaderfile
instead and link to the class from header file documentation.
- QRecursiveMutex: QDoc doesn't allow shared documentation comments
for duplicating \fn docs between the base and deriving classes.
Remove the sharing, the function documentation is available under
'All Members' doc for QRecursiveMutex.
- QMultiMap: unite() and one overload of insert() were not recognized
because their definitions in the same header file interfered with
QDoc - use Q_CLANG_QDOC macro to comment them out, and tag \fn
comments to ensure that the function documentation is matched.
Change-Id: Ic96869904a72d92453e4ffa6901000147571969b
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Conflicts:
examples/widgets/graphicsview/boxes/scene.h
src/corelib/Qt5CoreMacros.cmake
src/corelib/Qt6CoreMacros.cmake
src/network/ssl/qsslsocket.cpp
src/network/ssl/qsslsocket.h
src/platformsupport/fontdatabases/windows/qwindowsfontenginedirectwrite.cpp
src/testlib/CMakeLists.txt
src/testlib/.prev_CMakeLists.txt
tests/auto/corelib/tools/qscopeguard/tst_qscopeguard.cpp
Disabled building manual tests with CMake for now, because qmake
doesn't do it, and it confuses people.
Done-With: Alexandru Croitor <alexandru.croitor@qt.io>
Done-With: Volker Hilsheimer <volker.hilsheimer@qt.io>
Change-Id: I865ae347bd01f4e59f16d007b66d175a52f1f152
Not important, but removes some ### Qt6 comments from my radar
Change-Id: Ifd1bf44c44ece8fa1314d3c7e0e95d1bd37ae0ea
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
This makes it easier to create one without having to create
a derivative class. The patch also adds a path to avoid using
QRunnable directly in QThreadPool.
Change-Id: I9caa7dabb6f641b547d4771c863aa6ab7f01b704
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
InheritPriority may not be set, but the warning only occurs on Windows.
Move the warning to the public class.
Change-Id: I51d401300f840e4c1396c2c30182e49ed45d60d2
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
Reviewed-by: Christian Tismer <tismer@stackless.com>
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Conflicts:
src/corelib/tools/qvector.h
Make QVector(DataPointer dd) public to be able to properly merge
5b4b437b30 from 5.15 into dev.
src/widgets/kernel/qapplication.cpp
tests/auto/tools/moc/allmocs_baseline_in.json
Done-With: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Change-Id: I929ba7c036d570382d0454c2c75f6f0d96ddbc01
The wait() functions with the unsigned long arg were marked for removal
for Qt6 but due to the high usage of this functions and the very small
gain, revert the deprecation.
Change-Id: I9c9b720d279a59d87730f51de0f321b3794aa88e
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
It doesn't seem to be working correctly with array of literal types,
blocking the patch refactoring the webgradient support:
10171: "painting/webgradients.cpp", line 79: error #28: expression must have a constant value
Change-Id: I9ddd768d24ef79dd7a69e23c91988d891e41d4b9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
The dummy implementation of QWaitCondition which is used when the thread
feature is not available lacks some functions which were recently added.
So we have to add them now.
Change-Id: I32720e0857a1bd3fcf0e70078404a38dd8a8ca88
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
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>
We recently added a call to setStackSize() in the QML thread, which
revealed that the dummy implementation for this function was missing
in no-thread builds.
Fixes: QTBUG-79571
Change-Id: Ibabb48d9cba73afda0842642045a2961e65523f9
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
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>
This is a temporary measure to work around an implementation bug on
Integrity: For all other platforms, QtPrivate::condition_variable is
just std::condition_variable. On Integrity, it's a class that wraps
QWaitCondition to provide the interface of std::condition_variable.
This allows the use of std::condition_variable across Qt without
running into the Integrity issue. Once we can depend on an more modern
Integrity toolchain, removing QtPrivate::condition_variable is a
simple mechanical change:
s/QtPrivate::condition_variable/std::condition_variable/g;
s/QtPrivate::mutex/std::mutex/g;
Task-number: QTBUG-78450
Change-Id: I293a99d1cdc48691817b926aa51ecd84556e5e90
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This reverts commit 319c478603.
Reason for revert: QTBUG-78450
Change-Id: Ifaea83626296508558591d4ff207d4e0c883f841
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
This reverts commit 5859f7d0d9.
Reason for revert: the blocker for qtdeclarative has been merged
(in qtdeclarative/c060f6e765a2f155b38158f2ed73eac4aad37e02).
Change-Id: Ie69cb1567417173f543e88f659658fe03ba28830
Reviewed-by: Liang Qi <liang.qi@qt.io>
It turns out that QWaitCondition is a std::condition_variable_any. The
_any variant works with any mutex type, but requires a native mutex
for the native condition variable. So, QWaitCondition and
std::condition_variable_any both require two different mutexes: the
one the user passes in, and an internal one.
std::condition_variable, however, only works with std::mutex, and
since both are backed by the native API, condition_variable can use
the mutex passed in by the user instead of having to use an internal
one.
So, port from 2 × QWaitCondition + QMutex (2 × native cond + 2 ×
native mutex + Qt mutex) to std::condition_variable + std::mutex (2 ×
native cond + native mutex), shaving the overhead of two additional
mutexes (one Qt, one native) as well as the memory allocation
performed by QWaitCondition (for its Private).
Speeds up the writeOnly case by ~1/8th:
PASS : tst_QReadWriteLock::writeOnly(QReadWriteLock)
RESULT : tst_QReadWriteLock::writeOnly():"QReadWriteLock":
- 39,703 msecs per iteration (total: 39,703, iterations: 1)
+ 34,950 msecs per iteration (total: 34,950, iterations: 1)
Change-Id: I196cb13a27242fc1cb99723dfab5b2e5f8522143
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Most of these are unique_locks because they call QWaitCondition::wait()
and it doesn't feel right to use qt_scoped_lock if the lock is dropped
within the scope.
Change-Id: I506eede63008dad135c21112e578da4f7684e528
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Ditch the QMutex *mutex() method that we had to keep around for binary
compatibility and drop the disambiguation argument of QMutex
&mutex(int) now that we don't need it anymore.
The lock_guard lines now look dangerously close to C++'s Most Vexing
Parse, so use braced initialization to make sure it's parsed as a
definition, not a declaration.
Change-Id: Ie3d70f58c9878ab6d7da8f8bd72a4cb4aff83bb7
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
- use qExchange() in cancel()
- use cancel() instead of manual pointer manipulations in the move ctor
Change-Id: Ica3a3a1e339500c5e5a0c0646e7a95c7c5d435db
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
- add missing explicit
- drop static from member functions that aren't static in the regular version
(ie. all functions)
As a drive-by, remove redundant inline keyword where it doesn't cause
wanton inconsistency with surrounding code.
Change-Id: I5aed73c3afa85d98d97b57c2c1874b1a5e664960
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We can't use qt_scoped_lock/qt_unique_lock here, so port to
std::unique_lock and std::lock_guard for now.
This is in preparation of deprecating QMutexLocker in favor
of std::unique_lock and std::scoped_lock.
In QFutureInterface, change the return type of mutex() from
QMutex* to QMutex&, so we don't need to deref when passing
to std::lock_guard. We need to keep the old method around
for BC reasons, so the new one needs an artificial function
argument for disambiguation. This will vanish come Qt 6.
Change-Id: I1a0f0205952a249512ec2dbd3f0f48dd209b1636
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>
Now that QRecursiveMutex is getting split off of QMutex, QMutexLocker
will stop working on QRecursiveMutex once the split has been finalized
in Qt 6.
Even today, QMutexLocker contains casts from QBasicMutex to QMutex
that some reviewers are uncomfortable with. One way to carry
QMutexLocker forward is to template it on the mutex type, possibly
with aliases like QBasicMutexLocker and QRecursiveMutexLocker. C++17
code would then not require a port, thanks to CTAD.
But we have the problem now, and we can't template QMutexLocker in Qt 5.
The alternative is to look at std and realize that they have surpassed
QMutexLocker in expressiveness already. A scoped_lock cannot be
unlocked again, a unique_lock can be moved around. QMutexLocker
doesn't do either. The only "problem" is that the std lock classes are
already templates, but we can't, yet, rely on C++17 CTAD to make them
look as if they weren't.
So, prepare for a future with C++17 CTAD by writing factory functions,
qt_scoped_lock and qt_unique_lock, which will later port mechanically
to their C++17 equivalents (mostly).
The functions are added to a new private qlocking_p.h becauee we don't
want to make them public. These are for use in Qt's own implementation,
or for users that don't care about compatibility and will not mind them
to be removed once we depend on C++17. Originally, I planned to use
qmutex_p.h instead, but that header is not self-contained and causes
build errors when we started to include it into libraries other than
QtCore.
Regarding the return value of qt_scoped_lock: Ideally, we'd like to
return a std::scoped_lock, but two things stand in the way: First,
scoped_lock was only added in C++17 (we fall back to lock_guard if
scoped_lock is not available). Second, returning one from a function
requires C++17 guaranteed copy elision, because neither scoped_lock
not lock_guard have a copy ctor. In order for code not to come to
depend on a particular lock class, we return any of lock_guard,
unique_lock or scoped_guard, depending on what the compiler supports,
and therefore wrap the functions in the unnamed namespace to avoid
running into ODR if (private) headers are used from different projects
(autotests, e.g.). By the time we can drop them, however, qt_*_lock
will be semantically 100% identical to their replacements.
Port some initial users.
Change-Id: I2a208ef2a4a533ee8e675812273986460e6b4d00
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The array of QAtomicPointer<QMutex> can be initialized using relaxed
stores of nullptr, since nullptr is the whole data. But once we store
an actual QMutex pointer in the array, we need to publish the indirect
data thus created. We did this, with testAndSetRelease(); what was
missing was a corresponding acquire fence on load, without which there
is no happens-before relationship between the writes performed by the
QMutex ctor and the reads performed by a subsequent mutex.lock(), say,
on the same data.
Fix by adding acquire fences to all loads. That includes the dtor,
since mutexes may have been created in different threads, and never
been imported into this_thread before the dtor is running.
As a drive-by, return a new'ed QMutex that was successfully installed
directly to the caller, without again going through a load-acquire.
Fixes: QTBUG-59164
Change-Id: Ia25d205b1127c8c4de0979cef997d1a88123c5c3
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 65b8f59e04)
(cherry picked from commit da38f0d691d9d7eacfac5fbcbd47b887bd59bd39)
If this function is called by multiple threads, more than one could
reach the mutex locking and call TlsAlloc(), but only the last one would
save the data. The others would be leaked and, worse, be used by those
other threads.
[ChangeLog][QtCore][QObject] Fixed a resource leak caused by a race
condition if multiple QObjects were created at the same time, for the
first time in an application, from multiple threads (implies threads not
started with QThread).
Fixes: QTBUG-77238
Change-Id: Ife213d861bb14c1787e1fffd15b63a5818bcc807
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
These were hidden in !QT_CONFIG(thread) code. The irony!
This patch does not change the semantics of the operations. It
just makes the implicit operations explicit.
Any fixes or optimizations are left for follow-up patches, if any.
Change-Id: I014eb71745532dae2efe7963aa87321f61b1bd7a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Also reduce the pool size from 131 to 17, and use QBasicMutex
instead of recursive ones.
Change-Id: I3bf0374cce5ff2c07427070aba6128a22c9b70e4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Move the recursive mutex use case out of QMutex into a separate class,
unsurprisingly called QRecursiveMutex. As an immediate benefit, 90% of
the QMutex users now enjoy a constexpr QMutex ctor.
This change prepares for a real split in Qt 6, so that both use-cases
are no longer bundled up in one class.
[ChangeLog][QtCore][QMutex] Added QRecursiveMutex as a replacement of
QMutex(QMutex::Recursive).
Change-Id: I79b8724e8a8ee65e4bd0f06acd76103fe4197b8c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The default stack size is too small on RTEMS.
Qt uses threads internally and there is no way to change their stack
size.
Change-Id: I94a42c7a70c745f0b50d7051d9320edfabd1e09e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The array of QAtomicPointer<QMutex> can be initialized using relaxed
stores of nullptr, since nullptr is the whole data. But once we store
an actual QMutex pointer in the array, we need to publish the indirect
data thus created. We did this, with testAndSetRelease(); what was
missing was a corresponding acquire fence on load, without which there
is no happens-before relationship between the writes performed by the
QMutex ctor and the reads performed by a subsequent mutex.lock(), say,
on the same data.
Fix by adding acquire fences to all loads. That includes the dtor,
since mutexes may have been created in different threads, and never
been imported into this_thread before the dtor is running.
As a drive-by, return a new'ed QMutex that was successfully installed
directly to the caller, without again going through a load-acquire.
Change-Id: Ia25d205b1127c8c4de0979cef997d1a88123c5c3
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
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>
This reverts commit 79bdc7cf1d.
We haven't ported every usages to loadRelaxed() / storeRelaxed() yet.
And warning as error is enabled in dev. We will revert this change
when new qt5 baseline got integrated.
Task-number: QTBUG-76611
Change-Id: I5b1f608fefbaca481311f376f22718f2c5047106
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Tell people to move to loadRelaxed() / storeRelaxed(), now that
we have them.
[ChangeLog][QtCore][QAtomicInteger] The load() / store() functions
have been deprecated in favor of loadRelaxed() / storeRelaxed().
[ChangeLog][QtCore][QAtomicPointer] The load() / store() functions
have been deprecated in favor of loadRelaxed() / storeRelaxed().
Change-Id: If7a31db2f90fce4a7605a2377067e86990646f48
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>
navigator.hardwareConcurrency can be accessed from
the main thread only. Read and cache the value on
QCoreApplication initialization.
Change-Id: I731f7f356ce106c7107977783d4b763326af06b6
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
qatomic.h included qbasicatomic.h which included qatomic.h.
Due to a define in qbasicatomic.h, the definitions from QAtomic would
change depending on which was included first. Fortunately qbasicatomic
does not need qatomic.h so the include can be removed.
Change-Id: I086009f2e16a6e20b2b76fc6b3bf66a343414206
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
Set name for pthread instead of "name too long" for easier tracking.
Change-Id: Iab22cbeac01277e4dc1325399c7892de2e5bd551
Reviewed-by: Timo Aarnipuro <timo.aarnipuro@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Wait for the result at the target index if the future
is running and the iterator index is past the current
result count.
Determine if there is a result at the target index
after waitForResult() returns, and return -1/end if
not.
Also support decrementing the end iterator. In this
case wait for the future to finish in order to get
the final result count.
Task-number: QTBUG-59811
Change-Id: I8fcc711bab2e72c3c5196a55b794d25e18bb324d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Plain load() / store() have already relaxed semantics. This
can be surprising -- std::atomic::load()/store() are actually
sequentially consistent -- and introduce a pain point
if someone wants to move from Qt atomics to std:: atomics.
So just add a suffix to the functions to clarify what's the
memory ordering involved with them.
The Ops::load / ::store are temporarily left in, because other
modules depends on them. We need to port those modules away,
then they can go (it's private API anyhow).
Similarly, not deprecating anything yet, except for marking
obsolete in the docs; there's a lot of code around using
load() / store() that needs to be ported first.
[ChangeLog][QtCore][QAtomicInteger] Added loadRelaxed() and
storeRelaxed(), to be used as replacements of load() / store().
[ChangeLog][QtCore][QAtomicPointer] Added loadRelaxed() and
storeRelaxed(), to be used as replacements of load() / store().
Change-Id: Iab0a78885050379e3740f0b039ba2bef28ce3bd2
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This allows QtDeclarative examples to build.
Change-Id: Icd20304f76f8ba15c94eaf01b9fcd7b151b16146
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Replace null and '\c nullptr' with \nullptr in the documentation.
Change-Id: Ib9e0cfc2eb2830b213e6523773603d56180b0998
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The timeout will never be larger than numeric_limits<quint64>::max(),
especially on platforms with 32-bit longs.
Instead, test if the timeout is exactly numeric_limits<unsigned long>::max(),
which matches the ULONG_MAX value which is documented
to indicate no timeout.
Change-Id: Ib663eddb5703797c50c04fd4eae60bd64f379d1c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
And take the opportunity to tell people not to sleep. It's always wrong.
Fixes: QTBUG-71757
Change-Id: I36203b7dac414e3eb9effffd1566b956dd05f32a
Reviewed-by: Lars Knoll <lars.knoll@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>
Avoid having the reset in waitForDone interfere with other uses of the
thread-pool by locking the mutex higher, and maintaining the state
so the queues doesn't have threads not in allThreads.
Task-number: QTBUG-62865
Change-Id: I17ee95d5f0e138ec15e785c6d61bb0fe064d3659
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The implementation calls GetCurrentThreadId, not GetCurrentThread, so
the return value is not the pseudo-handle.
Task-number: QTBUG-67686
Change-Id: Ifde0cf603dcea01bc1c454a8bebe1e5c0f22617f
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This update eliminates ALL parsing errors when clang parses the
Qt headers to build the precompiled header qdoc needs. These errors
are often cases where an old use of Q_QDOC no longer works because
clang sees the enclosed fake declarations as erroneous.
In a few cases, clang reported errors because two dummy function
declartations under the Q_CLANG_QDOC guard were indistinguishable,
so one of them was removed, and the documentation was patched
accordingly.
Using the macro Q_DECLARE_INTERFACE(...) causes clang to report errors
because the class parametewr is abstract. These uses of the macro are
not needed, so they are removed with #ifndef Q_CLANG_QDOC.
Some declarations of default GL types that had been provided for qdoc
were no longer needed, so they are removed.
Now there are some member function signatures in QDBusPendingReply
and QDBusPendingCall that have very long template clauses and qualifiers
in their signatures. These unwieldy signatures will be unnecessary in the
documentation and will look bad there, but for now they are correct. The
ultimate solution will be to add a metacommand to qdoc, something like
\simplify-signature to tell qdoc to generate the documentation for these
member functions without the long template caluses and qualifiers.
Change-Id: I012cf17a544fbba2ebc71002f31bdc865119bb8e
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Reviewed-by: Martin Smith <martin.smith@qt.io>
UWP also supports SwitchToThread. The usage of Sleep(0) was a leftover
that was forgotten when porting to desktop Window's approach of handling
threads.
Change-Id: I5e3d6fb3eefe07407b910cc6a6b45781d320e151
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
For winrt we cannot rely on the fact, that QThread::current will be called
from the correct thread for the first time. The application's main entry
point creates a suspended thread and starts it right afterwards. At that
moment, other functionality (QLoggingRegistry for example) might have
called QThread::current, which set the wrong thread as the main thread. In
order to avoid this situation, the main thread is explicitly set in
QCoreApplication's constructor.
Task-number: QTBUG-66418
Change-Id: I8b6347357a80eb395ae758bd3d420adef0826751
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
On Windows, the error code to be used with qErrnoWarning is not errno,
but Windows's GetLastError(). Obviously, right?
So don't pass errno to it, just let it get the error message straight
from qt_error_string(), which will use GetLastError().
Change-Id: I44e7d800c68141bdaae0fffd155619c93e3f3dab
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Replace by switch() where appropriate, remove else and unindent code
or simplify the return value.
Change-Id: Ie988b9068a9579ae5a899b3765e43aad480b564e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace by reinterpret_cast or const_cast, respectively.
Use auto when initializing a variable to fix Clang warnings
about repeating the type name, do minor tidying along the way,
and a few conversions of 0 or NULL to nullptr.
Change-Id: Ieb271a87ddcf064f536e1ff05d23b1e688b1b56a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add QtCore, fixing:
qthreadstorage.h includes qscopedpointer.h when it should include QtCore/qscopedpointer.h
Amends 815153d4a4.
Change-Id: I8424bc4d0b0d666dbd04d63530af4fbd27987628
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
We can reuse the main QThread definition for the no-thread
configuration and avoid having to keep them in sync.
Add stub definitions for member functions where needed.
Change-Id: I128db11684a6040d09c4a4ce114f1399cba523f8
Reviewed-by: Lorn Potter <lorn.potter@gmail.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>
Add implementation for the no-thread configuration:
Assume access will only happen from one thread and
use a QScopedPointer to hold the data.
Unlike the real implementation this version will
delete the stored data on destruction, as opposed
to on QApplication destruction.
Change-Id: I9d8e89e7da18f967f463e2db7b50549c962acc84
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Set data->threadId, which makes the thread detection
used by Qt::AutoConnection work: it will now actually
select Qt::DirectConnection.
Change-Id: I9369e47eb7ed3ec88dba25f2d41e92139958bcd7
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
In some places we call startingUp(), in others we don't. It's probably
ok for those that have just created an object of a given class, which
knows whether the virtual call is necessary or not. But for the generic
case, we do call it.
Change-Id: If48c5c2e920c433298f1fffd153ee1cc75703204
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
So that users don't get a warning if using
-Wzero-as-null-pointer-constant
Change-Id: Ia15b5f380a2f6a93e05eec06646608e480cdf5d2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
.qdoc files should only be licensed under FDL (for documentation) or
BSD (if they only contain code).
Change-Id: I2a8a5b2c7bd3f927b8f71506c3672bc4916aca1e
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
We cannot inline methods of QThreadPrivate because QThreadData has to
be declared before. The global QThreadData needs to be accessible to
QThreadData::clearCurrentThreadData(), and QAdoptedThread::run() has to
be moved inside the #ifndef QT_NO_THREAD block as run() doesn't exist
in the stub and Q_DECL_OVERRIDE would be wrong.
We also fix the QThreadData::current() method to take and use the same
parameters as in the non-stub case.
Change-Id: Id29ca44b11fa95ed2df7cc39243a07ce7d3c455e
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Mike Achtelik
Alexandru Croitor
Jarek Kobus
Thiago Macieira
André Klitzing
Giuseppe D'Angelo
Andrei Golubev
Oliver Wolff
Allan Sandfeld Jensen
Sona Kurazyan
Samuli Piippo
Vitaly Fanaskov
Qt Forward Merge Bot
Morten Johan Sørvig
Timur Pocheptsov
Lars Knoll
Topi Reinio
Liang Qi
Jan Arve Sæther
Friedemann Kleint
Sze Howe Koh
Nico Vertriest
Christian Ehrlicher
Tor Arne Vestbø
Eskil Abrahamsen Blomfeldt
Volker Hilsheimer
Marc Mutz
Jani Heikkinen
Tasuku Suzuki
Mikhail Svetkin
Venugopal Shivashankar
Paul Wicking
Janne Koskinen
Lorn Potter
Alessandro Portale
Martin Smith
Cristian Maureira-Fredes
Andy Shaw
Ulf Hermann
Albert Astals Cid
Kai Koehne