summaryrefslogtreecommitdiffstats
path: root/src/corelib/thread/qfutureinterface_p.h
Commit message (Collapse)AuthorAgeFilesLines
* QFutureInterfaceBasePrivate: pack to remove paddingThiago Macieira2022-12-061-3/+3
| | | | | | | | | | | | | This structure was 216 bytes with 3 padding regions: 3 bytes between continuationState and refCount, 4 bytes between m_progressValue and m_progress, and 1 byte at the end after the booleans. The total of 8 bytes can be neatly reduced. And since it's now a multiple of 16, we should get an effective 16 byte reduction in malloc()ed size. Change-Id: I69ecc04064514f939896fffd172e46d1d68cb28b Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QFuture: fix handling of cancelled continuation chainSona Kurazyan2022-09-211-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Revert "QFutureCallOutEvent: de-export again"Sona Kurazyan2022-07-061-1/+5
| | | | | | | | | | | | QFutureCallOutEvent is used externally, so it needs to be exported. This reverts commit 3141a13b2a5c3cf770e072e49d43c86f376688e5. Fixes: QTBUG-104732 Pick-to: 6.4 Change-Id: I82c9e7414192ee948f78259bd74a404691a7805a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Marc Mutz <marc.mutz@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>
* QFutureCallOutEvent: remove unused pseudo-copy-ctorMarc Mutz2022-04-151-12/+0
| | | | | | | | | This constructor was used in the previous implementation of clone(). The current implementation uses the compiler-generated copy-constructor. Change-Id: Ibae163653e43ceb2b07872b496cd004e50b1e625 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QFutureCallOutEvent: de-export againMarc Mutz2022-04-141-1/+1
| | | | | | | | | | | | A previous commit Q_CORE_EXPORTed this class so it could be used in tst_qevent. But we can also keep it Q_AUTOTEST_EXPORTed and make the testing of the class subject to QT_BUILD_INTERNAL on the test side. That's what this patch does. Change-Id: I9bd5f80ada856b7db4b39dfb59b32bd825416c13 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* QEvent: start to de-inline copy ctor and clone() of all subclassesMarc Mutz2022-04-141-7/+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>
* Export QFutureCallOutInterface to allow external useSona Kurazyan2022-02-091-1/+1
| | | | | | | | | | | 2dea20e4b075f2367a069793ece2327eff5ac4bd 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>
* QFutureCallOutInterface: de-inline dtorMarc Mutz2022-01-051-1/+1
| | | | | | | 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/+1
| | | | | | | | | | | | | | | | | | | 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>
* QException: Fix no-exception buildNodir Temirkhodjaev2021-06-141-0/+2
| | | | | | | | | | 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>
* Allocate progress related data on demandSona Kurazyan2021-06-121-5/+10
| | | | | | | | | | | | | | | | 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-3/+18
| | | | | | | | | | | | | | 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>
* Merge integration refs/builds/qtci/dev/1616415197Qt CI Bot2021-03-221-16/+17
|\
| * QFutureInterfaceBasePrivate: reorder members to save 8 bytesFabian Kosmale2021-03-221-16/+17
| | | | | | | | | | | | | | | | 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/+2
|/ | | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Disable copying and assigning of QEventVolker Hilsheimer2020-11-191-0/+1
| | | | | | | | | | | | | | 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>
* Allow cloning of event objectsVolker Hilsheimer2020-11-171-1/+1
| | | | | | | | | | | | 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>
* Deprecate the pause-related APIs of QFuture* classesSona Kurazyan2020-06-041-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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 - add ability to move results from QFutureTimur Pocheptsov2020-03-311-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Port from QAtomic::load() to loadRelaxed()Giuseppe D'Angelo2019-06-201-2/+2
| | | | | | | | | | | | | | | 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>
* Make QT_NO_FUTURE a featureUlf Hermann2017-12-191-0/+2
| | | | | | | | | | | ... 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>
* Merge remote-tracking branch 'origin/5.7' into 5.8Liang Qi2016-11-241-1/+1
|\ | | | | | | | | | | | | | | | | Conflicts: src/network/socket/qnativesocketengine_winrt.cpp tools/configure/configureapp.cpp tools/configure/environment.cpp Change-Id: Ieae6f2ee004a87f041751852b687484f91ee4480
| * Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-11-231-1/+1
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This also reverts commit 0d2f0164f45cb626c40a7c95026ba00fa56ac249. Conflicts: header.BSD-NEW qmake/Makefile.win32 src/openglextensions/qopenglextensions.cpp src/openglextensions/qopenglextensions.h src/winmain/qtmain_win.cpp src/winmain/qtmain_winrt.cpp tools/configure/configureapp.cpp util/glgen/qopenglextensions.cpp.header util/glgen/qopenglextensions.h.header Change-Id: If26c6f4111b342378dd88bbdc657e322d2ab6ad8
| | * QFutureInterface: make accesses to 'state' thread-safeMarc Mutz2016-11-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Make sure all private headers in Qt Core include qglobal_p.hThiago Macieira2016-06-251-0/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.6' into devLiang Qi2016-02-021-4/+6
|\| | | | | | | | | | | | | | | | | Conflicts: config.tests/unix/compile.test src/plugins/platforms/cocoa/qcocoahelpers.mm src/tools/qlalr/cppgenerator.cpp Change-Id: I0103ca076a9aca7118b2fd99f0fdaf81055998c3
| * QFutureInterface: add missing mutex lock to progress gettersMarc Mutz2016-01-191-4/+6
| | | | | | | | | | | | | | | | | | | | 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>
* | Updated license headersJani Heikkinen2016-01-151-14/+20
|/ | | | | | | | | | | 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>
* Update copyright headersJani Heikkinen2015-02-111-7/+7
| | | | | | | | | | | | | | | | | | 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>
* Update license headers and add new license filesMatti Paaso2014-09-241-19/+11
| | | | | | | | | - Renamed LICENSE.LGPL to LICENSE.LGPLv21 - Added LICENSE.LGPLv3 - Removed LICENSE.GPL Change-Id: Iec3406e3eb3f133be549092015cefe33d259a3f2 Reviewed-by: Iikka Eklund <iikka.eklund@digia.com>
* QFutureInterface: allow to work with a QThreadPool != globalInstance()Marc Mutz2014-08-051-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* QFutureInterface: remove unused member variable 'pendingResults'Marc Mutz2013-09-201-1/+0
| | | | | Change-Id: I059580831ed29a53186272283aa7695c57539eed Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* Update copyright year in Digia's license headersSergio Ahumada2013-01-181-1/+1
| | | | | Change-Id: Ic804938fc352291d011800d21e549c10acac66fb Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Fix for leak in QFutureChristian Strømme2012-11-011-1/+25
| | | | | | | | | | | 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>
* Move QFutureWatcher back to QtCoreMarc Mutz2012-09-281-1/+1
| | | | | | | | This belongs with QFuture. Change-Id: I555cd01c1d3890fbbaca4fd8a9170292ea4eb0fb Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Move QFuture from QtConcurrent to QtCoreMarc Mutz2012-09-281-0/+167
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>