summaryrefslogtreecommitdiffstats
path: root/src/corelib/thread/qfutureinterface.cpp
Commit message (Collapse)AuthorAgeFilesLines
* QFutureInterface: remove comment that was never trueMårten Nordheim2024-03-151-2/+1
| | | | | | | | | Even in the original patch where the comment was added the callouts were made with the lock held. Change-Id: Id8d122010d2195d83ddd4fdaf638f7fc4ac8163d Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QFutureWatcher: Fix race for initial emission of resultReadyAt()Jarek Kobus2024-03-151-16/+10
| | | | | | | | | | | | | | | | | | | | | | When connecting a QFutureWatcher to the QFuture it will connect to the output interface, which will queue up events to notify about the current state. This happens in the thread of the QFutureWatcher. Since 07d6d31a4c0c17d8c897d783a9b0841df6834b02 unfortunately the sending of those events was done outside the lock, meaning the worker-thread could _also_ send events at the same time, leading to a race on which events would be sent first. To fix this we move the emission of the events back into the lock and because it is now inside the lock again anyway, we will revert back to posting the callout events immediately, so this patch also partially reverts 07d6d31a4c0c17d8c897d783a9b0841df6834b02 Fixes: QTBUG-119169 Pick-to: 6.7 6.6 Change-Id: If29ab6712a82e7948c0ea4866340b6fac5aba5ef Reviewed-by: Arno Rehn <a.rehn@menlosystems.com> Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
* QFutureInterface: Rename "interface" variables to "iface"Nodir Temirkhodjaev2024-03-051-13/+9
| | | | | | | | | | On Windows the "interface" is defined as "struct". Do not #undef it to fix a unity build. Task-number: QTBUG-122980 Pick-to: 6.7 Change-Id: I9379c996d8b67b16a8b825af0ff3469111533291 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QFuture: immediately delete watcher after the context is destroyedIvan Solovev2024-01-091-1/+1
| | | | | | | | | | | | | | | | | | We used deleteLater(), which was triggering ASAN use-after-free error. Apparently, what could happen is that after the context was destroyed, we called deleteLater(), but if at this point the previous future got finished, we still tried to emit watcher->run() to execute the continuation. And then the watcher got deleted. This patch replaces deleteLater() with a plain delete call. This looks safe, because the watcher is only accessed while holding the lock. Amends 59e21a536f7f81625216dc7a621e7be59919da33. Fixes: QTBUG-120302 Pick-to: 6.7 6.6 Change-Id: Ia32f20bfe8daea2e2346f3d446c978ae305d2f68 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QFuture: Don't use QFutureCallOutInterface for continuationsArno Rehn2023-12-131-69/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch replaces the QBasicFutureWatcher that was used for continuations with context objects with a smaller QObject-based wrapper that works directly from the actual continuation. The idea stays the same: In order to run continuations in the thread of a context object, we offload the continuation invocation to the signal-slot mechanism. Previously, we've hooked into QFuture with QFutureCallOutInterface to emit a signal and trigger continuation invocation. However, it is much easier and robust to emit that signal from the continuation itself. This sidesteps the locking issues that QFutureCallOutInterface handling presents. QFutureCallOutInterface basically requires any consumer to only access the QFuture after all events have been posted and the internal mutex unlocked, i.e. on the next cycle of the event loop. Continuations do not impose this restriction; runContinuation() explicitly unlocks the internal mutex before calling the continuation. This fixes a deadlock when using QFuture::then(context, ...) where the paren future is resolved from the same thread that the context object lives in. Fixes: QTBUG-119406 Fixes: QTBUG-119103 Fixes: QTBUG-117918 Fixes: QTBUG-119579 Fixes: QTBUG-119810 Pick-to: 6.7 6.6 Change-Id: I112b16024cde6b6ee0e4d8127392864b813df5bc Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Make qYieldCpu() public APIThiago Macieira2023-07-251-1/+0
| | | | | | | | | | | Rewritten to be a bit simpler, added a few more yield/YieldProcessor alternatives, added RISC-V support. [ChangeLog][QtCore] Added qYieldCpu() function. Fixes: QTBUG-103014 Change-Id: I53335f845a1345299031fffd176f59032e7400f5 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* QFutureInterface: port to new SlotObjUniquePtrMarc Mutz2023-07-191-5/+1
| | | | | | | | | ... removing a ### comments to that effect. Pick-to: 6.6 Change-Id: I635ca9593ec72a66d328ff6de61cd311c1b4e89f Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* QBasicFutureWatcher: get rid of the PrivateMarc Mutz2023-07-131-23/+12
| | | | | | | | It's not needed anymore, because the class is no longer part of the ABI. Pick-to: 6.6 Change-Id: Idfacc6023288ce603b30ab5aa904106e8c850444 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Move QBasicFutureWatcher behind the ABI boundaryMarc Mutz2023-07-131-1/+81
| | | | | | | | | | | | ... and out of QtPrivate. No inline API requires it anymore, so move it into the only TU using it. Can't move it into the unnamed namespace because of the friend declaration in QFutureInterfaceBase. Pick-to: 6.6 Change-Id: I27452960492bc1193a4d0eaeb2acd913d4dd02a5 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* QFuture: Extract Method watchContinuation() (DRY && SCARY)Marc Mutz2023-07-131-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old code violated the following principles: - DRY: the same code occurred 3× in the code-base - SCARY: the vast majority doesn't actually depend on template arguments, causing template bloat Solve both with a tiered Extract Method. We cannot change the order of the operations performed on QBasicFutureWatcher, in particular not the connect() to the contination w.r.t. setFuture(), so we cannot leave the connect to the continuation lambda outside the function, as it would mean to also leave the setFuture() call outside. Thanks to Volker's makeCallableObject(), we can, however, type-erase the lambda using QSlotObjectBase, which is what connect() internally creates, anyway, therefore bringing the whole function behind the ABI boundary. As a non-QObject, non-QMetaObject friend, we're lacking support for actually doing something useful with a QSlotObjectBase, but that can be fixed in the implementation now. The interface is stable, which is what matters for 6.6 now. This will allow a subsequent commit to drag QBasicFutureWatcher behind the ABI boundary, unexporting it. Saves a whopping 8KiB in tst_qfuture text size on optimized C++20 Linux AMD64 GCC9 builds. Pick-to: 6.6 Done-with: Fabian Kosmale <fabian.kosmale@qt.io> Change-Id: I0e5c2564907d92f6938689ab249be11fc0332ba5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Arno Rehn <a.rehn@menlosystems.com> Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* ThreadPoolThreadReleaser: add Q_NODISCARD_CTORMarc Mutz2023-07-131-0/+1
| | | | | | | QUIP: 19 Pick-to: 6.6 Change-Id: I465a2ef8edc103f0655a7732f3aaaf18748854c4 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix segfault when using qfuture continuations with move only typesAhmed Essam2023-06-101-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using move-only types, continuations args are set using takeResult function, which has the side effect of invalidating the QFutureInterface associated with the promise/futures by: 1. setting isValid to false 2. setting the state to NoState And when the promise is destroyed, it tries to run the continuations if `finished()` is not called, which is done by checking the Finished bit in the state. But since the continuation has been run before, and the state has been set to NoState it tries to run the continuation again causing a segfault. Multiple solutions come in mind: 1. don't run the continuation if the state is NoState, but this would break the case when an empty promise is destroyed 2. check inside the continuation if it has been run before, and if so don't run it again, but this seems hacky since we don't want the continuation to be run twice, and it should break if it did. 3. when invalidating the promise leave the state as is, and change isValid only to false, which changes the current behavior, but is still compatible with the documentation which states only that isValid will return false if takeResult is called I chose option 3 I also extended some tests to test for move only types, and added a test that continuations run when a promise is finished. This simple case would segfault before with move only types. Fixes: QTBUG-112513 Pick-to: 6.5 6.6 Change-Id: Ie225ac4fdf618e4edfb0efd663d6c7fd6b916dbd Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* QFuture: Gracefully handle a destroyed context in continuationsArno Rehn2023-05-301-20/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch relaxes the requirements on the context object of continuations. Instead of having to stay alive during execution of the whole chain, it now only has to stay alive during setup of the chain. If the context object is destroyed before the chain finishes, the respective future is canceled. This patch works by using QFutureCallOutInterface and signals instead of direct invocation of the continuation by the parent future, similar to how QFutureWatcher is implemented. If a continuation is used with a context object, a QBasicFutureWatcher is connected to the QFuture via a QFutureCallOutInterface. When the future finishes, QBasicFutureWatcher::finished() triggers the continuation with a signal/slot connection. This way, we require the context object to stay alive only during setup; the required synchronization is guaranteed by the existing event and signal-slot mechanisms. The continuation itself does not need to know about the context object anymore. [ChangeLog][QtCore][QFuture] Added support for context objects of continuations being destroyed before the continuation finishes. In these cases the future is cancelled immediately. Fixes: QTBUG-112958 Change-Id: Ie0ef3470b2a0ccfa789d2ae7604b92e509c14591 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Misc.: Fix some narrowing integral conversion warningsAhmad Samir2023-04-251-1/+1
| | | | | | | Drive-by change: use QByteArrayView instead of allocating a QByteArray. Change-Id: Iaf7acbbdb4efbb101b73b30061ce38dd1fa99ca3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Long live QtFuture::makeReadyVoidFuture() and QtFuture::makeReadyValueFuture()Ivan Solovev2023-04-051-0/+13
| | | | | | | | | | | | | | | | [ChangeLog][QtCore][QFuture] Added QtFuture::makeReadyVoidFuture() and QtFuture::makeReadyValueFuture(). Basically, these methods behave like QtFuture::makeReadyFuture(), but QtFuture::makeReadyValueFuture() does not have a "const QList<T> &" specialization returning QFuture<T> instead of QFuture<QList<T>>, which allows it to always behave consistently. This patch also introduces usage of the new methods around qtbase. Task-number: QTBUG-109677 Change-Id: I89df8b26d82c192baad69efb5df517a8b182995f Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QFutureInterface: add a warning when an existing continuation is overwrittenIvan Solovev2023-03-281-0/+4
| | | | | | | | | ... and also extend the documentation to explain this case explicitly. Fixes: QTBUG-107545 Pick-to: 6.5 6.2 Change-Id: I9414cc677b037989de60e97871485018e5c8a569 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QFuture: fix continuation cleanupIvan Solovev2023-02-151-0/+1
| | | | | | | | | | | | | | | | Not clearing the continuationData could lead to use-after-free when there is an attempt to cancel an already finished future, which belongs to an already-destroyed promise. This patch fixes it be explicitly resetting continuationData to nullptr in the clearContinuation() method, which is called from the QPromise destructor. Task-number: QTBUG-103514 Pick-to: 6.5 6.4 6.2 Change-Id: I6418b3f5ad04f2fdc13a196ae208009eaa5de367 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Port from container.count()/length() to size()Marc Mutz2022-10-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is semantic patch using ClangTidyTransformator: auto QtContainerClass = expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o) makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container'. <classes> are: // sequential: "QByteArray", "QList", "QQueue", "QStack", "QString", "QVarLengthArray", "QVector", // associative: "QHash", "QMultiHash", "QMap", "QMultiMap", "QSet", // Qt has no QMultiSet Change-Id: Ibe8837be96e8d30d1846881ecd65180c1bc459af Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QFuture: fix handling of cancelled continuation chainSona Kurazyan2022-09-211-19/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To support cancellation of continuations attached via the parent future, for each future returned by a continuation we store a pointer to its parent (i.e. future the continuation is attached to). Later, before executing a continuation, we go through chain of parents and check if any of them is cancelled. However, if one of the parents is destroyed while the chain is executing, the next continuations' parent pointers will become invalid. So storing the parent pointers isn't safe. This commit changes the logic of handling the cancelled continuation chain in the following way: - Instead of storing a parent pointer in the continuation future's data, we do the opposite: we store a pointer to continuation's future in the parent. - When a future is cancelled, we mark all continuation futures in the chain with a flag indicating that the chain is cancelled. - To guarantee that the pointers to continuation future's data don't become invalid, we clean the continuation (that stores a copy of its future's data and keeps it alive) only when the associated promise is destructed, instead of cleaning it after the continuation is run. Fixes: QTBUG-105182 Fixes: QTBUG-106083 Pick-to: 6.2 6.3 6.4 Change-Id: I48afa98152672c0fc737112be4ca3b1b42f6ed30 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Move QFutureInterfaceBase::cleanContinuation() to removed_apiSona Kurazyan2022-06-221-12/+0
| | | | | | | | | | This method isn't used anymore, but we can't remove it entirely for BC reasons, because it was called from inline code. Pick-to: 6.4 Change-Id: I9183c666c466030787ac7c2386706b50abf23eaa Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Fix typos in docs and commentsKai Köhne2022-06-151-1/+1
| | | | | | | | | Found by codespell Pick-to: 6.4 Change-Id: Ie3e301a23830c773a2e9aff487c702a223d246eb Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-161-38/+2
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Atomics: workaround GCC 12 warning about overflowing d->stateThiago Macieira2022-05-111-0/+5
| | | | | | | | | | | | | | | | | | I don't see a way this can be anything but a bogus warning. In member function ‘std::__atomic_base<_IntTp>::__int_type std::__atomic_base<_IntTp>::fetch_or(__int_type, std::memory_order) [with _ITp = int]’, inlined from ‘static T QAtomicOps<X>::fetchAndOrRelaxed(std::atomic<T>&, typename QAtomicAdditiveType<T>::AdditiveT) [with T = int; X = int]’ at qatomic_cxx11.h:449:33, inlined from ‘T QBasicAtomicInteger<T>::fetchAndOrRelaxed(T) [with T = int]’ at qbasicatomic.h:168:36, inlined from ‘int switch_on(QAtomicInt&, int)’ at qfutureinterface.cpp:97:31, inlined from ‘void QFutureInterfaceBase::setThrottled(bool)’ at qfutureinterface.cpp:194:18: atomic_base.h:648:33: warning: ‘unsigned int __atomic_or_fetch_4(volatile void*, unsigned int, int)’ writing 4 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=] A few more of those appear in other modules. I'm not fixing them all, assuming GCC will soon fix the warning. Pick-to: 6.2 6.3 Change-Id: I7fb65b80b7844c8d8f26fffd16e93f68e278d048 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QFutureInterface: use (new) qYieldCpu() instead of _mm_pause()Marc Mutz2022-04-301-15/+6
| | | | | | | | | | | | | | | | | | | | | | | This loop here was a lonesome instance of a CAS loop in which adding _mm_pause() was simple, because the code didn't use the usual pattern do { construct new value } while (!testAndSet) we use everywhere else in Qt. In search of an elegant pattern that would allow to apply qYieldCpu()/_mm_pause() to those idiomatic CAS loops, too, I've reached for a lambda to construct the new value. This should apply to all (tight) CAS loops, and may form the basis of an API extension whereby we take that lambda as a function argument to encapsulate the CAS loop in an algorithm (a function). Pick-to: 6.3 Change-Id: Id4a8f174dd812aa26f0b163e943bd4558e5e6a7b Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* QFutureInterface: insert x86 PAUSE in tight CMPXCHG loopThiago Macieira2022-04-261-2/+11
| | | | | | | | | | | | | | | | | From the Intel Software Optimization Manual[1], Chapter 11 ("Multi-core and Hyper-Threading Technology"), offers: User/Source Coding Rule 14. (M impact, H generality) Insert the PAUSE instruction in fast spin loops and keep the number of loop repetitions to a minimum to improve overall system performance. See section 11.4.2 for an explanation of why this is a good idea. [1] https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html#inpage-nav-5 Pick-to: 6.3 Change-Id: I7fb65b80b7844c8d8f26fffd16e94088dad1ceee Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* QEvent: start to de-inline copy ctor and clone() of all subclassesMarc Mutz2022-04-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no advantage to them being inline: Absent de-virtualisation, clone() is only supposed to be called through the vtable, and the copy ctor is only supposed to be used in the implementation of clone(). And when the compiler de-virtualises, we don't want the code duplication associated with inlining. Enforce this by introducing new macros to hide the boilerplate. This fixes missing out-of-line dtors in: - QSinglePointEvent - QApplicationStateChangeEvent - QFutureCallOutEvent Wrong covariant return in: - QFutureCallOutEvent And missing clone() reimplementations in: - QCloseEvent - QIconDragEvent - QShowEvent - QHideEvent - QDragEnterEvent - QDragLeaveEvent While these don't carry extra data or members, a dynamic_cast of the result of clone() as well as using the expected covariant return value would fail: QShowEvent *e = ~~~; QShowEvent *e2 = e->clone(); // ERROR: converting QEvent* to QShowEvent* Check that reimplementing clone() is binary compatible (covariant returns may change the numerical pointer value returned, cf. https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B). The copy-assignment operator stays inline for the time being, as the goal is to = delete it in the future. This patch covers, roughly, QtCore and QtGui. [ChangeLog][QtGui][QEvent subclasses] Fixed missing clone() reimplementations on QCloseEvent, QIconDragEvent, QShowEvent, QHideEvent, QDragEnterEvent, and QDragLeaveEvent. Task-number: QTBUG-45582 Task-number: QTBUG-97601 Change-Id: Ib8a0519dbe85a7a8da61050d48be338004dfa69a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QFutureInterface: optimize atomic loadMarc Mutz2022-04-051-1/+1
| | | | | | | | | | | | | | As all other 20+ users of the state variable, use a relaxed atomic load under the protection of the mutex. There's no need for the loadAcquire() that the implicit conversion operator uses under the hood, because a) we're under mutex protection and b) the state doesn't guard any other data but itself. Found by disabling said implicit conversion operators. Change-Id: I2a76242271cec96175cde503ca883805db6b9212 Reviewed-by: David Faure <david.faure@kdab.com> Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Optimize ContinuationWrapper used for support of move-only continuationsSona Kurazyan2022-01-211-1/+1
| | | | | | | | | | | | | | | After QFuture continuations became non-copyable (see earlier commits), we have to always use ContinuationWrapper to save the continuations inside std::function, since it requires the callable to be copyable. Optimize the wrapper, by storing the callable directly (instead of using a ref-counted QSharedPointer) and introducing a fake copy-constructor that makes sure that it's never called. Pick-to: 6.3 6.2 Change-Id: I0ed5f90ad62ede3b5c6d6e56ef58eb6377122920 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Fix memory leaks when capturing a QFuture in its continuationSona Kurazyan2022-01-211-1/+14
| | | | | | | | | | | | | | | | | | | | | | Capturing a QFuture in the continuations attached to it results in memory leaks. QFuture's ref-counted data can only be deleted when the last copy referencing the data gets deleted. The saved continuation that keeps a copy of the future (as in case of the lambda capture) will prevent the data from being deleted. So we need to manually clean the continuation after it is run. But this doesn't solve the problem if the continuation isn't run. In that case, clean the continuation in the destructor of the associated QPromise. To avoid similar leaks, internally we should always create futures via QPromise, instead of the ref-counted QFutureInterface, so that the continuation is always cleaned in the destructor. Currently QFuture continuations and QtFuture::when* methods use QFutureInterface directly, which will be fixed by the follow-up commits. Fixes: QTBUG-99534 Pick-to: 6.3 6.2 Change-Id: Ic13e7dffd8cb25bd6b87e5416fe4d1a97af74c9b Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QFutureCallOutInterface: de-inline dtorMarc Mutz2022-01-051-0/+2
| | | | | | | Pick-to: 6.3 Task-number: QTBUG-45582 Change-Id: I5f3411e1dcea4b76fb0e729f612516db3163c93a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QFuture: support cancellation of continuation chain through parentSona Kurazyan2021-11-131-0/+28
| | | | | | | | | | | | | | | | | | | 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>
* Optimize QPromise destructorSona Kurazyan2021-10-081-4/+26
| | | | | | | | | 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>
* Allocate progress related data on demandSona Kurazyan2021-06-121-24/+52
| | | | | | | | | | | | | | | | 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: put the result store and the exception store in a unionSona Kurazyan2021-06-121-22/+51
| | | | | | | | | | | | | | 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>
* QFutureInterface(Base): code tidiesGiuseppe D'Angelo2021-06-081-2/+2
| | | | | | | | | | | | | | | | 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>
* QPromise/QFutureInterface: in Qt 7 take std::exception_ptr by const-refGiuseppe D'Angelo2021-06-081-0/+4
| | | | | | | | | | | 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>
* QPromise/QFuture: fix value semanticsGiuseppe D'Angelo2021-05-221-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge integration refs/builds/qtci/dev/1616415197Qt CI Bot2021-03-221-3/+1
|\
| * QFutureInterfaceBasePrivate: reorder members to save 8 bytesFabian Kosmale2021-03-221-3/+1
| | | | | | | | | | | | | | | | And use in-class member initialization where applicable. Task-number: QTBUG-92045 Change-Id: I54715709f2d8e54017311f45016c16d86ed3078b Reviewed-by: Karsten Heimrich <karsten.heimrich@qt.io>
* | QFuture: cleanup headersFabian Kosmale2021-03-221-0/+5
|/ | | | | | | | | | | | | | 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>
* Fix memory leaks in QFuture's continuationsSona Kurazyan2020-12-011-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Track progress range in QFutureInterface::setProgressValueIvan Solovev2020-11-171-1/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix QFuture::waitForFinished to wait until QFuture is startedSona Kurazyan2020-08-261-2/+2
| | | | | | | | | | | | | | | | | 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>
* Introduce swap functions for QPromise/QFutureInterfaceAndrei Golubev2020-08-031-1/+6
| | | | | | | | | | 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>
* Add QPromise implementationAndrei Golubev2020-06-091-0/+36
| | | | | | | | | | | | | | | | | | | | | | 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>
* Deprecate the pause-related APIs of QFuture* classesSona Kurazyan2020-06-041-24/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add a way of notifying QFutureWatcher when pause is in effectSona Kurazyan2020-05-291-4/+25
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* Store QFuture exceptions as std::exception_ptrSona Kurazyan2020-04-011-0/+9
| | | | | | | | | | | 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 - add ability to move results from QFutureTimur Pocheptsov2020-03-311-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add support for attaching continuations to QFutureSona Kurazyan2020-03-051-4/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-21 07:55:27 +0000