Unify cancel and finish in QPromise destructor in a single call. This
saves us one extra mutex lock and atomic state change.
Task-number: QTBUG-84977
Change-Id: Iac06302c39a2863008b27325fcf6792d4f58c8ae
Reviewed-by: Mårten Nordheim <marten.nordheim@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>
refT()/derefT() can be marked noexcept; we don't care about not
overflowing the refcounter as a precondition. (This is BC, as no
compiler mangles noexcept.) This in turn allows to mark a constructor
calling refT() as noexcept.
Driveby: mark also the same functions to not be `const` in Qt 7.
They clearly are meant to modify *this, and constness only works
because of the unmanaged (raw) d-pointer.
Change-Id: I8d7d365640ff2e1cedc0a234c9abccdfc95ba6e3
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
std::exception_ptr is a reference-counted "smart pointer", so we
shouldn't copy it around freely. Unfortunately QFutureInterface
has exported functions taking it by value, so we can't just change
the signatures and keep BC. Simply prepare the code for Qt 7.
Change-Id: Ic5aae6a095c8c842872a40db440c99d2dfe371f1
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
In random order:
* QFutureInterfaceBase has a d-pointer, and copy semantics. So,
"naturally" extend it to support move semantics as well. (These get
used by QPromise/QFuture, as they both hold a QFutureInterface*
as a data member). The only addition needed is a check for a null
d-pointer in the destructor.
Drive by, reorganize the code for the copies, and use copy-and-swap
instead of the hand-rolled solution. Also, add a free swap()
overload, and mark the existing one as candidate for inlining
in Qt 7 (doesn't need to be an exported function).
* QFutureInterface inherits QFutureInterfaceBase, again with value
semantics. To be honest, I'm not sure why QFutureInterfaceBase is
polymorphic -- could be a design mistake, as polymorphic classes
don't mix with value semantics. Anyways, reorganize the code for
copies, apply copy-and-swap, and add move semantics. This requires
adding a check into derefT().
* Finally, QPromise was already move-only, but had broken move
semantics: the move constructor was not noexcept (!) and it actually
allocated memory (!!!). Fix that one (can be defaulted now), and
streamline the move assignment via the proper macro.
Drive by, fix the signature of the constructor from QFutureInterface
(take const-ref, not plain ref -- it's eventually copied, so it
can keep the const), and add another internal constructor from
rvalue QFutureInterface that moves from it.
Change-Id: I9d61a9dd4d45f34942d8f34416baa118c0307390
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@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>
Previously QFutureInterface::setProgressValue was silently ignoring
the progress range and allowed to set any progress value.
Also no checks were performed in QFutureInterface::setProgressRange,
which allowed the user to set minimum > maximum.
Add checking of the current progress range, when settings the
progress value.
Add checks for minimum and maximum values while setting the progress
range.
The implementation of the checks is mostly based on the logic
that is used in QProgressBar.
- If maximum is smaller than minimum, minimum becomes the only legal
value.
- If the current progress value falls outside the new range, the
progress value is set to be minimum.
- If both progressMinimum() and progressMaximum() return 0, the
current progress range is considered to be unused, and any progress
value can be set.
- When setting the value using setProgressValue(), if the value falls
out of the progress range, the method has no effect.
Task-number: QTBUG-84729
Change-Id: I29cf4f94b8e98e1af30dd46fbdba39c421cf66bf
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Currently QFuture::waitForFinished() exits as soon as the future is not
in the running state. If the user calls it before
QPromise::reportStarted() is called, it will exit immediately, because
nothing is running yet. Fix the behavior to wait for the finished state.
[ChangeLog][Important Behavior Changes][QtCore] Fixed the behavior of
QFuture::waitForFinished() to wait until the future is actually in the
finished state, instead of exiting as soon as it is not in the running
state. This prevents waitForFinished() from exiting immediately, if at
the moment of calling it the future is not started yet.
Task-number: QTBUG-84867
Change-Id: I12f5e95d8200cfffa5653b6aa566a625f8320ca8
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Made QPromise::swap public, added free standing swap() for
QFutureInterface and QPromise. Updated QPromise special member
functions. Extended tests
Task-number: QTBUG-84977
Change-Id: I5daf6876df306d082441dbcdf5ae4dee3bfc0ead
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>
Deprecated the pause-related APIs of QFuture* classes and
added alternatives having "suspend" in the name instead.
With 2f15927f01ceef0aca490746302a5ea57ea9441c 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>
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>
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>
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>
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>
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>
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>
After including windows.h, interface is a define that expands to
"struct" (unless WIN32_LEAN_AND_MEAN is defined). This name is
used as a normal identifier in multiple places within Qt.
This has already been worked around in a number of places
(in e.g. 3ba61d9baa569ea69e41a943981680c09c521ff7 and
786d23bb4966b6697ac04c43158e2312d898e133).
After qrandom.h was included in <QtCore/QtCore>, this header
implicitly includes <random>. In libc++ on windows, this header
then transitively includes windows.h, exposing the clash with
the name "interface" in even more locations than before.
For cases within qtbase internals, it could also alternatively be
handled by defining WIN32_LEAN_AND_MEAN while building QtDbus, but
for occurrences in public headers, the undef trick needs to be
used.
Change-Id: I89754f38f55ae7f2145255a2c8a71b23492be6a1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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>
This fixes a problem that occurs when a task, that is run synchronously,
throws an exception. If that happened, then the exception would not be
re-thrown, because of an early return.
Task-number: QTBUG-54831
Change-Id: Ic70c5b810ec6adce6e62bfd6832ba9f170b13a7f
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
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>
[ChangeLog][QtCore][QThreadPool] Added QThreadPool::cancel() which allows
removing from the job queue a job that hasn't been started yet.
Change-Id: Ib8f1c1f32a34f5eec8338c641d820b928e470164
Reviewed-by: Nick Shaforostoff <shafff@ukr.net>
Reviewed-by: Olivier Goffart <ogoffart@woboq.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>
Rationale: a wait on a condition-variable is usually a cancellation point.
On Posix, and probably in C++ at some point, a thread cancellation is
done by (a kind of) exception unwinding the stack. To ensure that
we call reserveThread() in all cases, wrap the function pair in a RAII
class. Even if we currently don't seem to support exceptions in QtCore,
this is low-hanging fruit, and no worse than what we had before.
Change-Id: Ifb0f428ea50f9ac12be14e620615f46e00d3dd91
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Remove all trailing whitespace from the following list of files:
*.cpp *.h *.conf *.qdoc *.pro *.pri *.mm *.rc *.pl *.qps *.xpm *.txt *README
excluding 3rdparty, test-data and auto generated code.
Note A): the only non 3rdparty c++-files that still
have trailing whitespace after this change are:
* src/corelib/codecs/cp949codetbl_p.h
* src/corelib/codecs/qjpunicode.cpp
* src/corelib/codecs/qbig5codec.cpp
* src/corelib/xml/qxmlstream_p.h
* src/tools/qdoc/qmlparser/qqmljsgrammar.cpp
* src/tools/uic/ui4.cpp
* tests/auto/other/qtokenautomaton/tokenizers/*
* tests/benchmarks/corelib/tools/qstring/data.cpp
* util/lexgen/tokenizer.cpp
Note B): in about 30 files some overlapping 'leading tab' and
'TAB character in non-leading whitespace' issues have been fixed
to make the sanity bot happy. Plus some general ws-fixes here
and there as asked for during review.
Change-Id: Ia713113c34d82442d6ce4d93d8b1cf545075d11d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Following 731ba8ed08f80644b403556638c7f6229e678ebe this function is
not used anymore
Change-Id: Id908931b4b21c825bd80a4f03790630818c73c07
Reviewed-by: Christian Stromme <christian.stromme@digia.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>
