Replace phrases like "future has been running", "parent" with more
precise descriptions.
Pick-to: 6.1 6.2
Fixes: QTBUG-95273
Change-Id: Ibd5a464007d41cc437da49ba250b9ea0a46078c6
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
We will not gain anything if we have to do multiple function calls to
obtain the thread id. Therefore we introduce a macro to signal that we
have a fast implementation of currentThreadId, and only use the function
if it is defined.
Pick-to: 6.2
Change-Id: I3347489ea91992896bb753b796ae26e391c2c99c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
When inserting items into the result store, a ResultItem is created,
which stores a pointer to the results list and their size. If the size
of the ResultItem is set to 0, it means that a single result is stored.
In case of trying to report results via an empty list, the size is 0, so
result store treats it as a single result.
Added checks before storing the results to make sure that the result
list isn't empty. Note that empty lists are allowed in some cases for
the filter mode, because ResultStoreBase::addResults() knows how to
handle those cases correctly.
Task-number: QTBUG-80957
Pick-to: 5.15 6.1 6.2
Change-Id: I399af4c3eef6adf82fea5df031fe9a9075006b1f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
All the getters of QFutureWatcher are consistent with the getters of the
corresponding QFuture, except for the isFinished() method, which returns
'true' only after the finished() signal is delivered. This behavior
might be unintuitive for the users. In particular, isFinished() returns
'false', even if it's called immediately after waitForFinished().
[ChangeLog][QtCore][QFutureWatcher][Important Behavior Changes] The
QFutureWatcher::isFinished() method now indicates if the related
QFuture is finished, instead of indicating if the finished() signal was
delivered. This makes it consistent with the future that is being
watched.
Fixes: QTBUG-91048
Pick-to: 6.1 6.2
Change-Id: I6ae9b882b23e06198a82c95b026491bd480b3bf0
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QMetaType now implicitly knows how to convert any QFuture<T> to
QFuture<void> without needing to manually register a converter
function.
QtWebChannel will make use of this to transparently support QFuture<T>
return types.
[ChangeLog][QtCore][QMetaType] QMetaType now supports converting any
QFuture<T> to QFuture<void>.
Task-number: QTBUG-92903
Change-Id: Ied7e71be37c346cc3d2c274ffb0d91a6821ab4d4
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
For generic interop with other parts of Qt, we need to be able to
extract the type-erased internal storage of QFuture<T>. In particular,
QtWebChannel needs this to transparently support QFuture<T> as a method
return type.
Task-number: QTBUG-92903
Change-Id: I763f054656b8810d58720262d364baf42c47eb37
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Revert a part of d3638e18d3 because the
change was not needed
Task-number: QTBUG-94407
Pick-to: 6.2
Change-Id: I7cf0969d6ecc4078d38b4241ffe7d24273a6d412
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
... and C++20 std::counting_semaphore API compatibility.
[ChangeLog][QtCore][QSemaphore] tryAcquire() now optionally takes a
<chrono> duration as timeout, not just int milliseconds.
[ChangeLog][QtCore][QSemaphore] Added try_acquire{,_for,_until}() for
C++20 std::counting_semaphore compatibility.
Change-Id: I34b6b4bf57a54745d4b97349903d090c4995338a
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
QMutexLocker is declared in qmutex.h, which is already included.
Pick-to: 6.2
Task-number: QTBUG-94407
Change-Id: I78e0630c27ef7f85feae68e98f8cdcbe4e142cd8
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Copying a QOrderedMutexLocker is questionable, and would currenly easily
lead to UB. Therefore we delete the copy ctor and copy assignment
operator, and implement well-behaving move operators.
In addition, provide an explicit dismiss method for cases where we don't
want the locker to unlock the mutexes, as they have been manually
unlocked (this could have been implemented previoulsy by using the copy
assignment operator).
Pick-to: 6.2 6.1 5.15
Change-Id: If2a888710e1c74277b28fd3e2939ab26fff0c7ae
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@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>
Add a noexcept from a doc signature that was missing it.
Change-Id: I30b429a6ec4d182551ca68767d1c8aa61c9e4c09
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@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>
QFuture shouldn't be passed by value: it's a reference counted
class ("shared future").
Change-Id: I3890062c45f9a6470b278223b88d482f57bf68a0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Get rid of a reduntant initialization; a data member gets default
initialized anyways.
Change-Id: I85ad4c9a00b3066ccd993dfc2652a3f0164a860e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
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>
The check is over-arching. is_move_constructible is sufficient;
we don't have to support "ridiculous" types that are copiable but
have deleted move operations (such types are fundamentally broken).
This is in line with the Move* (legacy) named requirements.
Change-Id: Idc7116b39013501b9be39628a4e7afd35fe15530
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Either the mix of futex and atomic, or the mix of 32-bit futex and
64-bit atomic doesn't work. In any case, the existing code leads to
bad behavior.
Pick-to: 6.1 5.15
Fixes: QTBUG-92188
Change-Id: Icc6ba28d6e2465c373d00e84f4da2b92c037e797
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The documentation for QCoreApplication::exit() even refers to it as
such. Instead of refactoring the documentation to explain that it isn't,
just make it a slot and do the same for the other classes.
Complements 2e6c37fe51.
[ChangeLog][QtCore][QEventLoop] exit() is now a slot, like quit().
[ChangeLog][QtCore][QThread] exit() is now a slot, like quit().
Change-Id: Ic42004c9bf71440eb433fffd167f4a1b89bcac80
Reviewed-by: David Faure <david.faure@kdab.com>
QFuture already has a constructor from QFuture<T> to QFuture<void>. It's
safe to remove this function, since it couldn't be ever used: it tries
to access QFuture's private member, which leads to compilation error. It
was never documented or tested.
Change-Id: Iaed9602e2737455d159012ea18ca241954e1f7df
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Even if the user (usually accidentally) sets a thread count of zero or
negative. The reporter in the bug report did
QThread::idealThreadCount() - 1 on a 1 CPU system...
Drive-by add to the documentation and the missing #include.
Pick-to: 6.1 6.0
Fixes: QTBUG-93007
Change-Id: I6cdea00671e8479b9c50fffd167807d14e030154
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
During reportFinished we may call a continuation which might end up
triggering one of the signals.
Pick-to: 6.0 6.1
Change-Id: I19546fcca12be71cd536e4287eb5eddd9d236830
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It was mistaking semaphore values over 0 as waiters, regardless of
actual waiters.
Pick-to: 6.1
Change-Id: Icebd01592ca8bdc1687a29dc569e3b630a262606
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We do this by making the 'futexNeedsWakeAllBit' to be part of both the
expectedValue and the pointer we're waiting on.
This makes sense since having the 'futexNeedsWakeAllBit' set is a
requirement for starting a sleep. Thus we should condition
sleeping on whether or not another thread unset it.
Since the futexNeedsWakeAllBit is in the "topmost" bit of the pointer we
wait on we'll need to use the full 64-bits on 64-bit platforms.
This isn't enabled (nor was it an issue) for configurations with
'futexHasWaiterCount' since that works differently, and waits for the
high 32 bits.
Fixes: QTBUG-92148
Change-Id: I424c605f0120ea5e647c5bb19b00ff35eaf1608a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We might return false a few lines down, without decreasing the count.
Change-Id: I0a90c07f279860987e41539e9d5f3b5d2cb15207
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If the pool has a name. This should make identifying threads belonging
to different pools easier in process-inspection tools.
Fixes: QTBUG-92004
Change-Id: Id2983978ad544ff79911fffd167225902efeb855
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Currently, QThreadPool's generated threads inherit the priority from the
thread they are created and that cannot be changed. This merge request
adds a property to QThreadPool so that the priority of the threads can
be different.
The default behavior does not change.
[ChangeLog][QtCore][QThreadPool] QThreadPool can now be configured to
use a different thread priority when creating new threads than the one
it inherits from the thread it was created in. This will only apply to
the threads started after the property is changed.
Fixes: QTBUG-3481
Change-Id: Ic98d4312d055a3357771abb656516ebd0715918d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
As this method is rather critical for performance of some central
parts of Qt, it really should be inline whereever possible. This
commit adds an inline implementation for Windows 32 and 64 bit.
Amends 5e9b2ade67
Change-Id: Iea51ef905b1cb7f91ca64b718d79bdc4f5c02c3a
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
The code was already there, just only implemented for Linux.
Change-Id: Ib709fc1585f647a98d54fffd16663881b6d24d6f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Be more precise about attaching a continuation with the default
(QtFuture::Launch::Sync) launch policy after a continuation with
context.
Pick-to: 6.1
Change-Id: I5b80063df2443e5742033864ba012bf34ed4cdf7
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Windows 8 added this pair of functions that can be used to implement the
same functionality as we have on Linux. For ease of understanding, I'm
calling them "futex" on Windows too.
From Qt 6 our minimum platform is Windows 10 so we can use this
unconditionally.
Change-Id: Ifea6e497f11a461db432ffff1448c6806ecfc36c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This reverts commit 8f8405e046.
Reason for revert: Appears not entirely thread-safe and caused QTBUG-90705
Change-Id: I390c0b1a555a18e6a095b52010371d017071e26b
Fixes: QTBUG-90705
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Ported all properties, except activeThreadCount. Marking it dirty may
cause a re-evaluation of properties depending on it, which may reault in
a deadlock in case of trying to read activeThreadCount property which is
being marked as dirty.
Task-number: QTBUG-85520
Change-Id: Id073b0895c89a9e6b05b57ad520db994e550a1c9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Sona Kurazyan
Fabian Kosmale
Nico Vertriest
Arno Rehn
Tasuku Suzuki
Marc Mutz
Nodir Temirkhodjaev
Giuseppe D'Angelo
Paul Wicking
Allan Sandfeld Jensen
Thiago Macieira
Volker Hilsheimer
Mårten Nordheim
Samuel Gaist
Lars Knoll
Qt CI Bot