summaryrefslogtreecommitdiffstats
path: root/src/corelib/thread
Commit message (Collapse)AuthorAgeFilesLines
* Mention QPromise in the QFuture docsSona Kurazyan2021-03-161-3/+4
| | | | | | | Change-Id: I5f6930116da534dd1dea41c4724c42104de38877 Reviewed-by: Paul Wicking <paul.wicking@qt.io> (cherry picked from commit 0477f6b15a2d71d47c39e52b5da140d19aa76f31) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Improve docs for QFuture::then() with contextSona Kurazyan2021-02-261-0/+10
| | | | | | | | | | | | | | Be more precise about attaching a continuation with the default (QtFuture::Launch::Sync) launch policy after a continuation with context. 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> (cherry picked from commit 5624b35d6514c5439b9d6dc639dc71228ca7b5ca) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Revert "Port QThreadPool to the new property system"Allan Sandfeld Jensen2021-01-293-42/+17
| | | | | | | | | | This reverts commit 8f8405e04642b98663d4752d4ae76c304ae33b01. 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>
* Port QThreadPool to the new property systemSona Kurazyan2021-01-273-17/+42
| | | | | | | | | | | 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>
* Update QMutexLocker documentationLars Knoll2021-01-261-1/+1
| | | | | | | | | And add an entry about the API changes to qt6-changed.qdoc. Pick-to: 6.0 Task-number: QTBUG-89429 Change-Id: I146574acd3e4aa5ed6f1629fc68888f009472f19 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove the qmake project filesJoerg Bornemann2021-01-071-83/+0
| | | | | | | | | | | | | | | | Remove the qmake project files for most of Qt. Leave the qmake project files for examples, because we still test those in the CI to ensure qmake does not regress. Also leave the qmake project files for utils and other minor parts that lack CMake project files. Task-number: QTBUG-88742 Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Doc: Use correct include for QtFuture namespacePaul Wicking2021-01-061-0/+1
| | | | | | | Pick-to: 6.0 Fixes: QTBUG-89766 Change-Id: I20c5d3c12490a5eed7bb4e267b2edb5d45dbaadf Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Call QEventDispatcher::startingUp() on thread startMorten Johan Sørvig2020-12-213-1/+2
| | | | | | | | | | | | | | | | ...instead of during createEventDispatcher(). This way, startingUp() will be called [on the thread being started] also for custom event dispatchers installed with QThread::setEventDispatcher(). This prevents crashes when installing event dispatches which expects that startingUp() will be called. Crash reproducible with test case from QTBUG-51961. Change-Id: I71bd696539689d928a61ff9b47d05297cf803b2f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add support of invoking QFuture continuations in a given contextSona Kurazyan2020-12-113-20/+211
| | | | | | | | | | | | Added overloads of .then()/.onFailed()/.onCanceled() which take a pointer of a context object, and invoke the continuations in the object's thread. Task-number: QTBUG-86794 Change-Id: I0f3cbb0500695673fc4087af5d4b96b416e3e1ce Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
* Remove unneeded qatomic_msvc.hChristian Ehrlicher2020-12-043-491/+0
| | | | | | | | | Since Q_COMPILER_ATOMICS is defined for every supportied MSVC compiler in qcompilerdetection.h, qatomic_msvc.h is not included anymore in qbasicatomic.h and can be removed. Change-Id: I6505da5d5e9f1c3f9a060ad30cabb4b652634aa3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix memory leaks in QFuture's continuationsSona Kurazyan2020-12-014-27/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix perfect forwarding of callables in QFuture's continuationsSona Kurazyan2020-12-012-28/+40
| | | | | | | | | | | | Use universal references instead of rvalue references for passing callables in the implementations of QFuture's continuations. Change-Id: I1288c78f78f84f30c6607e505e7f9807a9272071 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io> (cherry picked from commit b002722dabef794da0e80010b115b2c6cd6dc6b8) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Replace discouraged Q_MOVABLE_TYPE by Q_RELOCATABLE_TYPEAndreas Buhr2020-11-301-1/+1
| | | | | | | | | | | | | | Q_MOVABLE_TYPE was conceived before C++ had move semantics. Now, with move semantics, its name is misleading. Q_RELOCATABLE_TYPE was introduced as a synonym to Q_MOVABLE_TYPE. Usage of Q_MOVABLE_TYPE is discouraged now. This patch replaces all usages of Q_MOVABLE_TYPE by Q_RELOCATABLE_TYPE in QtBase. As the two are synonymous, this patch should have no impact on users. Pick-to: 6.0 Change-Id: Ie653984363198c1aeb1f70f8e0fa189aae38eb5c Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Add convenience functions for QFuture creationIvan Solovev2020-11-232-1/+170
| | | | | | | | | | [ChangeLog][QtCore][QFuture] Add convenience functions to create a ready QFuture and a QFuture with an exception Task-number: QTBUG-86713 Change-Id: Ic7f9ca590a8ea8a9696b84f35bad074780794461 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Sona Kurazyan <sona.kurazyan@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>
* Get rid of Q_COMPILER_CONSTEXPR checksAllan Sandfeld Jensen2020-11-172-15/+2
| | | | | | | Is required now. Change-Id: I62e95929d1649ea1390392230b619bd56d2a0349 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Track progress range in QFutureInterface::setProgressValueIvan Solovev2020-11-172-3/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* 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>
* Adjust code format, add space after 'if'Zhang Sheng2020-11-161-1/+1
| | | | | | Change-Id: Ice081c891ff7f4b766f49dd4bd5cf18c30237acf Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io> Reviewed-by: hjk <hjk@qt.io>
* Doc: Add missing brief statements for \property documentationTopi Reinio2020-11-121-7/+5
| | | | | | | | ... where applicable. Fixes: QTBUG-88232 Change-Id: I835df434765caededd35d5114965b4a1663e7942 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* QMutex: order reads from QMutexPrivate::waiters and QBasicMutex::d_ptr in ↵Alexander Kartashov2020-11-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QBasicMutex::lockInternal() Threads that unlock and lock a mutex at the same time perform the following operations: Thread 1 Thread 2 -------- -------- QBasicMutex::lockInternal() QBasicMutex::unlockInternal() d_ptr.testAndSetOrdered(..., d) d = d_ptr.loadAcquire() d->waiters.loadRelaxed(); (1) d->waiters.fetchAndAddRelease() (2) d_ptr.testAndSetRelease(d, 0) (3) d->derefWaiters() (4) d->waiters.testAndSetRelaxed(...) (5) if (d != d_ptr.loadAcquire()) (6) d->wait() The operation (1) isn't serialized with the operation (6) so its memory effect may be observed before the effect of the operation (1). However, if memory effects are observed in the following order: (6) -> (1) -> (2) -> (3) -> (4) -> (5) then Thread 1 doesn't notice that Thread 2 updates d_ptr and goes to sleep with d pointing to a stale object, this object isn't reachable since d_ptr is zeroed so Thread 1 cannot be woken up. The patch adds the "acquire" barrier into the operation (1) so that it cannot be reordered with the operation (6). Fixes: QTBUG-88247 Pick-to: 5.15 5.12 Change-Id: I1d0c405c0bf5080ec1815d351b9b4b75efeab21a Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Rename remaining QEvent variables to m_ convention; init m_reservedShawn Rutledge2020-11-101-1/+1
| | | | | Change-Id: I08694657b7c9d2713d0cb33519698dbba3bfdffa Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Resolve corelib's remaining ### Qt 6 commentsEdward Welbourne2020-11-021-2/+0
| | | | | | | | | | | | | No action taken at Qt 6, suggesting it shall never happen. Four removed, one converted to Qt 7, others converted to unversioned TODOs. Filed Jira tasks, and referenced in comments, for those retained. There remain two "once bootstrap builds are obsolete" comments and one other on which pending action may yet happen. Fixes: QTBUG-85700 Change-Id: Ib140a6a21c63370e51e4734cc591f67573a29d9a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Forbid implicit conversions between QFuture and other typesSona Kurazyan2020-10-302-21/+1
| | | | | | | | | | | | | | | | | | | | | - Remove the casting operator of QFuture<T> to T. It calls QFuture::result(), which may lead to undefined behavior if the user has moved the results from QFuture via QFuture::takeResult() before trying to do the conversion. - Disable implicit conversion of QFuture<T> to QFuture<void>, by making the constructor explicit. If the users really intend to do the conversion, they should do it explicitly. [ChangeLog][Source-Incompatible Changes][QFuture] Implicit conversions of QFuture<T> to T and to QFuture<void> have been disabled. Use QFuture::result() or QFuture::takeResult() where you need to convert QFuture<T> to T. Use the explicit QFuture<void>(const QFuture<T> &) constructor to convert QFuture<T> to QFuture<void>. Change-Id: I153d4137d36365b1611ac934fb3ac2eb667fdd6c Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
* Remove the comparison operators of QFutureSona Kurazyan2020-10-293-15/+1
| | | | | | | | | | | | | | These operators don't do what the user might expect and may lead to confusing results. [ChangeLog][Source-Incompatible Changes][QFuture] The comparison operators of QFuture have been removed. They were comparing the underlying d-ptrs instead of comparing the results (as the users might expect), which is not very helpful for the users point of view. Change-Id: I80a887610eac38b60329128cca52cdb5fb515207 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io> Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* QtConcurrent: Integrate runWithPromise into runJarek Kobus2020-10-281-3/+3
| | | | | | Change-Id: I6eb95aa66ff847e8bb9aac348fded3a5d55015b6 Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Store std::exception_ptr in QUnhandledExceptionSona Kurazyan2020-10-262-6/+96
| | | | | | | | | | | | | | | | For historical reasons Qt Concurrent reports QUnhandledException in case if an exception that is not derived from QException is thrown from a worker thread. Changing this behavior may not be a good idea, since the existing user code may rely on it. Changed QUnhandledException to wrap the std::exception_ptr to the actual exception, so that the users can obtain the information about the thrown exception if needed. [ChangeLog][QtCore][QUnhandledException] Improved QUnhandledException to store the std::exception_ptr to the actual exception thrown from a QtCocnurrent worker thread. Change-Id: I30e7c1d3e01aff6e1ed9938c421da0a888f12066 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QtConcurrent: Reuse ArgResolver from qfuture_impl.hJarek Kobus2020-10-261-0/+46
| | | | | | Task-number: QTBUG-83331 Change-Id: I572f68f6d3be4a50970d8d77d070f175be3ec785 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Use American "canceled" in QPromise docsAndrei Golubev2020-10-221-5/+5
| | | | | Change-Id: I4c416f52c7102750a77c3f91274dd0a235569d6e Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Whitespace cleanup in corelib/ mimetypes, plugin and threadAllan Sandfeld Jensen2020-10-2113-43/+42
| | | | | | | Done with selective application of clang-format Change-Id: Iee6bf2426de81356b6d480629ba972f980b6d93d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix qdoc warnings from QMutex and QMutexLockerVolker Hilsheimer2020-10-211-20/+7
| | | | | Change-Id: I25faab16ad2df3682e6c6b55d4aaff1c20402995 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Drop constexpr from QAtomicTraits::isLockFree()Edward Welbourne2020-10-201-19/+17
| | | | | | | | | As requested by a ### Qt 6 comment. This then implied a few other functions weren't constexpr, which broke some tests. Task-number: QTBUG-85700 Change-Id: I6522a9b2d7a74e117442121400a1d7198d323967 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QThread::create: mark as [[nodiscard]]Giuseppe D'Angelo2020-10-201-2/+2
| | | | | | | Also mark the helper function. Change-Id: I1469abf22cd132dbb1afe680121b6c928ffbe41e Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Inline the members for QRecursiveMutexLars Knoll2020-10-172-72/+36
| | | | | | | Avoid creating a a d pointer for recursive mutexes. Change-Id: I28af15a416ee17de346e2ea5b1442279d9d3e159 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* <chrono> should always be available with C++17Lars Knoll2020-10-171-6/+0
| | | | | Change-Id: Ia4868259bfa25e4b929a51de6de580df7277c282 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Split QMutex and QRecursiveMutexLars Knoll2020-10-176-243/+238
| | | | | | | | | | | | | | | | | | | | | | | These classes should not inherit from each other anymore in Qt 6. The reason is that this makes the 95% case of using a non-recursive mutex much slower than it has to be. This way, QMutex can now inline the fast path and be pretty much as fast as QBasicMutex is in Qt 5. They actually use the same code paths now. The main difference is that QMutex allows calling tryLock() with a timeout, which that is not allowed for QBasicMutex. [ChangeLog][QtCore][QMutex] QMutex does not support recursive locking anymore. Use QRecursiveMutex for that purpose. QRecursiveMutex does not inherit QMutex anymore in Qt 6. Change-Id: I10f9bab6269a9181a2e9f534fb72ce65bc76d989 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Refactor QMutexLocker to be able to handle recursive mutexesLars Knoll2020-10-173-44/+31
| | | | | | | | Since we're going to split QMutex and QRecursiveMutex into separate classes, make sure QMutexLocker is prepared for that. Change-Id: Id5e9a955d1db7c8ee663dd3811ad6448dad0aeae Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove redundant duplicate of EnableForNonVoid in QFutureWatcherAndrei Golubev2020-10-161-7/+1
| | | | | | | | | qfuturewatcher.h includes qfuture.h, which includes EnableForNonVoid through qfuture_impl.h header. Thus, there is never a need to keep the same alias in QFutureWatcher as it always can use one from QFuture Change-Id: I293fd087aea1a21ef5bcfdf50cdefc176a9703d0 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Fix subtle SFINAE problem in QPromise::addResultAndrei Golubev2020-10-161-3/+1
| | | | | | | | | | | | | | Accidentally found out that we enable/disable QPromise::addResult based on type deduced from input argument, instead of using "value_type" of QPromise itself, which is wrong Simplified the checks to a single one - EnableIfSameOrConvertible<InputType, StoredType> as this is sufficient to account for both cases: QPromise<void> and QPromise<T> with input, convertible to T Change-Id: I657998c0e26241b0fc5e70988622984ece8871df Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Rename QPromise starting and finishing methods to start and finishAndrei Golubev2020-10-162-13/+13
| | | | | | | | | Proposed during API review Change-Id: I9c43e1915c50803ab69bfe07a91c05d2224b86c4 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Make QPromise::addResult() return boolean status of operationAndrei Golubev2020-10-163-49/+56
| | | | | | | | | | | | | | | Changed QPromise::addResult() to return bool value. True is returned when result is added and false is returned when e.g. promise is in final state (canceled or finished) or when addResult() is called twice with the same index as argument (in which case new value is rejected) Updated QFutureInterface::reportFinished() that accepts optional result as argument to align with other result adding methods. This function is "internal" only (as of now), so no documentation update is needed Change-Id: I2d63069246e5e5c8cf04529c22bb296faaaae53d Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Reject overwrites by the same index in QPromise::addResult()Andrei Golubev2020-10-134-8/+49
| | | | | | | | | | | | One can call addResult(value, index) twice and consequently set the value twice by the same index. This seems rather strange and probably should not be allowed. This commit rejects setting results when there's already a valid result by that index. Consequently, this fixes memory leaks caused by N-times-called addResult(..., index) Fixes: QTBUG-86828 Change-Id: I77494f2cb73ce727ffad721cfcdcaa420899eb25 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Temporarily disable QFuture::takeResult() methodSona Kurazyan2020-10-123-25/+40
| | | | | | | | | | | | QFuture::takeResult() currently returns std::vector instead of QList, because QList does not support move-only types. Disable this method until QList is fixed to work with move-only types in Qt 6.1. Also did minor doc-fixes. Change-Id: I87feaf75d9433a3b540edd00039c3e21d6994985 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Fix build when configuring with -sanitize thread on gccMitch Curtis2020-10-121-1/+1
| | | | | | | | | There is no <sanitizer/tsan_interface.h> header when building with gcc, at least on Ubuntu 18.04.3. Fixes: QTBUG-87317 Change-Id: Ie933f6fa478f11b5062c665007e91be68e31ebe3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Make result finding procedure in ResultStore a free-standing functionAndrei Golubev2020-10-091-28/+38
| | | | | | | | | | Moved the logic of finding a result in ResultStore to separate function and parameterized it with QMap<...>. This is a pre-step to make find procedure uniform regardless of the storage we are looking in (either visible or pending as of now) Change-Id: I41641d70751925f223e992f52fbc7814085c452d Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Clear pending results in ResultStoreAndrei Golubev2020-10-091-9/+18
| | | | | | | | Pending results were never cleared by result store. This led to memory leaks when the results never transitioned to "visible" results Change-Id: I674302eb51542ad5f4d918da68d616428c73ae9f Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Another round of replacing 0 with nullptrAllan Sandfeld Jensen2020-10-072-2/+2
| | | | | | | | | This time based on grepping to also include documentation, tests and examples previously missed by the automatic tool. Change-Id: Ied1703f4bcc470fbc275f759ed5b7c588a5c4e9f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Centralize the implementation of move assignment operatorsGiuseppe D'Angelo2020-10-031-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment we have two main strategies for dealing with move assignment in Qt: 1) move-and-swap, used by "containers" (in the broad sense): containers, but also smart pointers and similar classes that can hold user-defined types; 2) pure swap, used by containers that hold only memory (e.g. QString, QByteArray, ...) as well as most implicitly shared datatypes. Given the fact that a move assignment operator's code is just boilerplate (whether it's move-and-swap or pure swap), provide two _strictly internal_ macros to help write them, and apply the macros across corelib and gui, porting away from the hand-rolled implementations. The rule of thumb when porting to the new macros is: * Try to stick to the existing code behavior, unless broken * if changing, then follow this checklist: * if the class does not have a move constructor => pure swap (but consider ADDING a move constructor, if possible!) * if the class does have a move constructor, try to follow the criteria above, namely: * if the class holds only memory, pure swap; * if the class may hold anything else but memory (file handles, etc.), then move and swap. Noteworthy details: * some operators planned to be removed in Qt 6 were not ported; * as drive-by, some move constructors were simplified to be using qExchange(); others were outright broken and got fixed; * some contained some more interesting code and were not touched. Change-Id: Idaab3489247dcbabb6df3fa1e5286b69e1d372e9 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Remove unnecessary ref-counting of QRunnableAllan Sandfeld Jensen2020-10-012-32/+7
| | | | | | | It could never be higher than 1 anyway. Change-Id: If33c7978a4397a08e9eb091926726725d8bd3ea6 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Fix race condition in QThreadPool::clearAllan Sandfeld Jensen2020-10-011-3/+3
| | | | | | | | | | | Since we drop the lock while deleting threads, we need to handle the queue possibly being accessed and changed by the pool threads while clear() is running. Pick-to: 5.15 Fixes: QTBUG-87092 Change-Id: I7611edab90520454278502a58621e299f9cd1f6e Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-21 08:40:51 +0000