2dea20e4b0 de-inlined the dtor to avoid
duplicating its vtable in multiple translation units, but the class is
used externally, so we need to export it now.
Pick-to: 6.3
Fixes: QTBUG-100569
Change-Id: I7cf2abdfdeb59bced0631838fe329ba94ab8c73a
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This change allows canceling the chain of continuations attached to a
future through canceling the future itself at any point of execution of
the chain.
[ChangeLog][QtCore][Important Behavior Changes] The chain of
continuations attached to a future now can be cancelled through
cancelling the future itself at any point of the execution of the chain,
as it was documented. Previously canceling the future would cancel the
chain only if it was done before the chain starts executing, otherwise
the cancellation would be ignored. Now the part of the chain that wasn't
started at the moment of cancellation will be canceled.
Task-number: QTBUG-97582
Change-Id: I4c3b3c68e34d3a044243ac9a7a9ed3c38b7cb02e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
qtbase\src\corelib\thread\qfutureinterface_p.h(180): error C2039: 'setException': is not a member of 'QtPrivate::ExceptionStore'
qtbase\src\corelib\thread\qexception.h(109): note: see declaration of 'QtPrivate::ExceptionStore'
Change-Id: Id746b87af3f88d91c473f6a3d986dc0f022dfa2f
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Some of the data members related to progress reporting (min, max and
text) aren't used when user doesn't want manual progress reporting, so
the data for them can be allocated on demand, when the user explicitly
sets them. Note, that we still need to always create other related data
(current value and progress timer), since in the non-manual mode
progress is still reported by incrementing the current value each time
a new result is reported.
Task-number: QTBUG-92045
Change-Id: I1e5bd17de2613a6ea72ccff0029812f67686708b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
QFuture doesn't need both at the same time, calling QFuture::result(s)
either returns a result or throws an exception. Store result and
exception stores in a union, to reduce the memory.
Also added a note for making the ResultStoreBase destructor non-virtual
in Qt 7.
Task-number: QTBUG-92045
Change-Id: I7f0ac03804d19cc67c1a1466c7a1365219768a14
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
And use in-class member initialization where applicable.
Task-number: QTBUG-92045
Change-Id: I54715709f2d8e54017311f45016c16d86ed3078b
Reviewed-by: Karsten Heimrich <karsten.heimrich@qt.io>
Do not include vector; we currently do not use std::vector, and the plan
is to use QList when that one supports move-only types.
Use QMutexLocker instead of std::mutex_locker, considering that the
former is already included with <QMutex>.
Use forward declarations where applicable.
Add header which were currently only indirectly included (to make
QtCreator's code model happy).
Change-Id: I37d5cd3982047a6d8a3132fd66571878298039b3
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Karsten Heimrich <karsten.heimrich@qt.io>
There were two issues:
- Some of the continuations were allocating memory for the
continuation's context dynamically, but deleting the allocated memory
only if they were actually invoked. Since the continuations may not be
invoked at all, this could cause memory leaks. Fixed by postponing the
allocations to the point when the continuations need to be invoked.
- In other cases the parent future is captured by copy in the
continuation's lambda, which is then saved in the parent. This causes
the following problem: the data of the ref-counted parent will be
deleted as soon as its last copy gets deleted. But the saved
continuation will prevent it from being deleted, since it holds a copy
of parent. To break the circular dependency, instead of capturing the
parent inside the lambda, we can pass the parent's data directly to
continuation when calling it.
Fixes: QTBUG-87289
Change-Id: If340520b68f6e960bc80953ca18b796173d34f7b
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Karsten Heimrich <karsten.heimrich@qt.io>
(cherry picked from commit 5d26d40a5596be048be87f309df9264bac741be9)
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Polymorphic classes should not be copied.
However, we do rely on event copying in our propagation logic. So, make the
members protected, don't delete them, using a dedicated macro.
This way, QMutable*Event classes can be used to make copies.
Remove some last usage of copying of QInputMethod(Query)Events.
Change-Id: Ia0a8ae4ca9de97dcd7788ca3c6ed930b6460c43a
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We have use cases for cloning of events, e.g. in the state machine and
for event propagation.
Provide the means to do so through a virtual method.
Adapt QFutureCallOutEvent::clone, which is now an override. No code
seems to be using that method.
Change-Id: I6864d6597f6de800343c4dc458a7994e84dc6fb4
Reviewed-by: Shawn Rutledge <shawn.rutledge@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>
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>
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>
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>
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>
... and make sure we can compile without it. In particular,
Qt Concurrent depends on QFuture, so we specify it as a condition,
and QtConcurrentException should not depend on future but on
concurrent.
Change-Id: I65b158021cecb19f227554cc8b5df7a139fbfe78
Reviewed-by: Martin Smith <martin.smith@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Introduce helper functions switch_{on,off,from_to} to make
the code more readable, and prepare everything for later
optimizations reducing the sizes of critical sections (by
locking the mutex later, or even never).
This commit, however, is only concerned with shutting up
tsan.
In waitForResult(), simplified the code by removing an
unneeded if guard: the condition is checked in the while
loop immediately following in the then-block, and the
local variable declaration that precedes the loop is not
worth guarding.
Change-Id: I24bfd864ca96f862302536ad8662065e6f366fa8
Reviewed-by: David Faure <david.faure@kdab.com>
The rule was:
- if the header included qglobal.h, turn that into qglobal_p.h
- otherwise, insert the #include after the "We mean it" warning
qglobal_p.h currently only includes qglobal.h.
Change-Id: Ib056b47dde3341ef9a52ffff13ef677e471674b7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
These variables are accessed from both the executing
thread as well as the thread waiting for results.
Note for some variables which threads access them.
Change-Id: I1c84ddff92585abb32341c42072106066e485f7e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)
Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
Background:
It is often necessary/advisable to schedule tasks on thread pools !=
globalInstance(). As Herb Sutter writes in
http://www.drdobbs.com/parallel/use-thread-pools-correctly-keep-tasks-sh/216500409
and the Qt Training Material stresses, tasks you schedule on a (global)
thread pool should be non-blocking, which currently rules out using any of
the QtConcurrent functions for, say, file I/O.
Nonetheless it's often convenient to have thread pools also for file I/O, as
the thumbnail viewer exercise in the Qt Training Material shows. In this
case, you'd use a dedicated thead pool, leaving the global thread pool for
CPU-bound tasks.
Yet, none of the QtConcurrent functions allow to pick the QThreadPool
instance on which to schedule the work created with them.
This patch prepares for them to do so.
This is the first part of the forward-port of
https://qt.gitorious.org/qt/qt/merge_requests/1281.
Implement by using a new QThreadPool* member that defaults to nullptr,
and adding setThreadPool to set this member, then using it in lieu of
QThreadPool::globalInstance() everywhere.
I chose to leave m_pool == nullptr to mean globalInstance() to avoid
creating the global instance whenever a QFuture is created, even if the
future represents the result of a calculation not run on the global thread
pool.
[ChangeLog][QtCore][QFuture] Can now be used with any QThreadPool, not
just globalInstance().
Task-number: QTBUG-17220
Change-Id: I4e1dc18d55cf60141b2fa3d14e2d44a3e9e74858
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
To avoid leaking when converting a QFuture<T> to a QFuture<void> we need
to have a separate ref. counter for QFuture<T>. When the last QFuture<T>
goes out of scope, we need to clean out the result data.
Task-number: QTBUG-27224
Change-Id: I965a64a11fffbb191ab979cdd030a9aafd4436c2
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
This class belongs to QThreadPool/QRunnable more than to QtConcurrent, so
move to QtCore, where QThreadPool awaits it.
Change-Id: Ibf20288a986593bf779453427c2dae8db1e1423a
Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Sona Kurazyan
Marc Mutz
Nodir Temirkhodjaev
Qt CI Bot
Fabian Kosmale
Volker Hilsheimer
Timur Pocheptsov
Giuseppe D'Angelo
Ulf Hermann
Liang Qi
Marc Mutz
Thiago Macieira
Liang Qi
Jani Heikkinen
Matti Paaso
Sergio Ahumada
Christian Strømme