summaryrefslogtreecommitdiffstats
path: root/src/corelib/thread/thread.pri
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* Remove unneeded qatomic_msvc.hChristian Ehrlicher2020-12-041-2/+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>
* Add QPromise implementationAndrei Golubev2020-06-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | 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>
* Add support for attaching continuations to QFutureSona Kurazyan2020-03-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Short live QtPrivate::{condition_variable,mutex}!Marc Mutz2019-09-271-0/+1
| | | | | | | | | | | | | | | | | | | | This is a temporary measure to work around an implementation bug on Integrity: For all other platforms, QtPrivate::condition_variable is just std::condition_variable. On Integrity, it's a class that wraps QWaitCondition to provide the interface of std::condition_variable. This allows the use of std::condition_variable across Qt without running into the Integrity issue. Once we can depend on an more modern Integrity toolchain, removing QtPrivate::condition_variable is a simple mechanical change: s/QtPrivate::condition_variable/std::condition_variable/g; s/QtPrivate::mutex/std::mutex/g; Task-number: QTBUG-78450 Change-Id: I293a99d1cdc48691817b926aa51ecd84556e5e90 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Short live qt_unique_lock/qt_scoped_lock! (until C++17)Marc Mutz2019-08-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that QRecursiveMutex is getting split off of QMutex, QMutexLocker will stop working on QRecursiveMutex once the split has been finalized in Qt 6. Even today, QMutexLocker contains casts from QBasicMutex to QMutex that some reviewers are uncomfortable with. One way to carry QMutexLocker forward is to template it on the mutex type, possibly with aliases like QBasicMutexLocker and QRecursiveMutexLocker. C++17 code would then not require a port, thanks to CTAD. But we have the problem now, and we can't template QMutexLocker in Qt 5. The alternative is to look at std and realize that they have surpassed QMutexLocker in expressiveness already. A scoped_lock cannot be unlocked again, a unique_lock can be moved around. QMutexLocker doesn't do either. The only "problem" is that the std lock classes are already templates, but we can't, yet, rely on C++17 CTAD to make them look as if they weren't. So, prepare for a future with C++17 CTAD by writing factory functions, qt_scoped_lock and qt_unique_lock, which will later port mechanically to their C++17 equivalents (mostly). The functions are added to a new private qlocking_p.h becauee we don't want to make them public. These are for use in Qt's own implementation, or for users that don't care about compatibility and will not mind them to be removed once we depend on C++17. Originally, I planned to use qmutex_p.h instead, but that header is not self-contained and causes build errors when we started to include it into libraries other than QtCore. Regarding the return value of qt_scoped_lock: Ideally, we'd like to return a std::scoped_lock, but two things stand in the way: First, scoped_lock was only added in C++17 (we fall back to lock_guard if scoped_lock is not available). Second, returning one from a function requires C++17 guaranteed copy elision, because neither scoped_lock not lock_guard have a copy ctor. In order for code not to come to depend on a particular lock class, we return any of lock_guard, unique_lock or scoped_guard, depending on what the compiler supports, and therefore wrap the functions in the unnamed namespace to avoid running into ODR if (private) headers are used from different projects (autotests, e.g.). By the time we can drop them, however, qt_*_lock will be semantically 100% identical to their replacements. Port some initial users. Change-Id: I2a208ef2a4a533ee8e675812273986460e6b4d00 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Inline QMutexPool into its only remaining userMarc Mutz2019-07-081-2/+0
| | | | | | | | | | Also reduce the pool size from 131 to 17, and use QBasicMutex instead of recursive ones. Change-Id: I3bf0374cce5ff2c07427070aba6128a22c9b70e4 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Modernize the "thread" featureUlf Hermann2018-08-171-51/+59
| | | | | | | | | | Add it to configure.json and replace all occurrences of QT_NO_THREAD with QT_CONFIG(thread). Add conditions for other features that depend on thread support. Remove conditions where we can use the QMutex and QThreadStorage stubs. Change-Id: I284e5d794fda9a4c6f4a1ab29e55aa686272a0eb Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
* Revert "Atomics: remove qatomic_msvc.h"Kai Koehne2018-06-011-0/+2
| | | | | | | | | | | | | | | | This reverts commit 90493e16b8dd9edc6176d0abc255422edbbb05c3. The change broke static builds with MSVC. [ChangeLog][Visual Studio] Reverted a change that caused static binaries compiled with Visual Studio 2015 to crash on start-up. Note that this does not apply to Visual Studio 2017 static binaries, even though the crash stack traces are very similar: with 2017, the problem is compiler regression and requires updating to version 15.8 for the fix. Task-number: QTBUG-68514 Change-Id: I67ea8e1ef442cecab83e7d8d74efc9617e02da35 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove src/corelib/arch, merging with src/corelib/threadThiago Macieira2018-03-191-0/+4
| | | | | | | There is no more architecture-specific code. Change-Id: Ie9d9215342d449c48a11fffd151d11411cd73fc7 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Make QT_NO_FUTURE a featureUlf Hermann2017-12-191-12/+18
| | | | | | | | | | | ... 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>
* Move the futex implementation to a headerThiago Macieira2017-09-181-0/+1
| | | | | | | So I can use it in QSemaphore and provide a Windows implementation. Change-Id: I6e9274c1e7444ad48c81fffd14dbc0a8e2201302 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Revert "Don't add qmutex_xxx.cpp to SOURCES, as qmutex.cpp #include's them"Oswald Buddenhagen2016-03-071-19/+15
| | | | | | | | | | | This reverts commit 40cbf1927bdd2fa9f531a047d1ba66f68c35d170 - the qmake parser bug this worked around has been fixed. As a side effect, the platform conditionals were simplified. Change-Id: Ibfc1253e3c2252ab954c725a9effd6e719cb691c Reviewed-by: Edward Welbourne <edward.welbourne@theqtcompany.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* Don't add qmutex_xxx.cpp to SOURCES, as qmutex.cpp #include's themThiago Macieira2015-08-061-12/+12
| | | | | | | | | | | | Normally qmake catches the #include and drops the source from SOURCES. But the parser has bugs, so help it by never adding the files. The false: SOURCES += is left so that the sources can be found by Qt Creator. Task-number: QTBUG-46582 Change-Id: I049a653beeb5454c9539ffff13e667877350346b Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
* Use qthread_win.cpp for WinRT as wellOliver Wolff2015-06-231-5/+0
| | | | | | | | | | Since of Windows (Phone) 8.1 most of the desktop's thread functionality is also available, so we might be able to share the code and get rid of the extra implementation for WinRT. Task-number: QTBUG-43837 Change-Id: I0ce907cd94899834527f88c70e1e395bafdb14b3 Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
* winrt: Use native threadingAndrew Knight2014-06-251-0/+5
| | | | | | | | | | | | | | | | | Instead of using std::thread, use the WinRT ThreadPool to manage threads. This allows for setting the scheduling priority, and provides a path to enable XAML integration (which requires Qt run on a background thread). QThread::terminate() is still unsupported, and only the winmain thread can be adopted due to the behavior of the thread pool when creating tasks from the GUI thread. The associated tests are now skipped, and all other QThread tests pass. Task-number: QTBUG-31397 Change-Id: Ib512a328412e1dffecdc836bc39de3ccd37afa13 Reviewed-by: Oliver Wolff <oliver.wolff@digia.com> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
* Remove all "old atomic" code from QtThiago Macieira2013-12-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The new atomic code was introduced in Qt 5.0. The platforms that did not get ported were announced as deprecated in Qt 5.2. The code is now removed in Qt 5.3. The status for the platform/compiler/OS combinations affected is: * Linux with GCC or Clang: still compiles on all platforms (via qatomic_cxx11.h or qatomic_gcc.h) * INTEGRITY with Green Hills compiler: no longer compiles * Solaris on UltraSPARC, with Sun Studio: no longer compiles * AIX on POWER5 or 6, with IBM Visual Age: no longer compiles (probably did not compile Qt 5.0 either) * VxWorks in kernel mode: no longer compiles [ChangeLog][General] Support for the following platforms has been removed, due to lack of interest in updating support: INTEGRITY, VxWorks, Solaris on UltraSPARC (with the Sun Studio compiler suite), AIX on POWER processors (with IBM Visual Age compiler suite). Change-Id: I8a961385fd95011c016b2b1eec52034794dae3e1 Reviewed-by: Olivier Goffart <ogoffart@woboq.com> Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com> Reviewed-by: Lars Knoll <lars.knoll@digia.com> Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
* Distinguish between 'mac' and 'macx' qmake scopesTor Arne Vestbø2013-03-051-1/+1
| | | | | | | | | | | | | | The former applies both on Mac OS X and iOS, but 'macx' is specific to Mac OS X. ios.conf and macx.conf now share most of their settings in the common mac.conf. We set the default QMAKE_MAC_SDK before loading mac.conf, so that any overrides in the device config will apply afterwards. This means configure's mkspec parsing will be able to read the QMAKE_MAC_SDK. Change-Id: I0c7e26a6a0103e19b23ef152aa9e4ab461cee632 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* Move QFutureSynchronizer back to QtCoreMarc Mutz2012-09-281-0/+1
| | | | | | | This class, too, belongs with QFuture. Change-Id: I41a532ca66c156f1631e4b22ffc1a5879c854488 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Move QFutureWatcher back to QtCoreMarc Mutz2012-09-281-0/+3
| | | | | | | | 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/+4
| | | | | | | | | 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>
* Move QtConcurrent::ResultStore as QtPrivate::ResultStore to QtCoreMarc Mutz2012-09-281-0/+2
| | | | | | | | | | No compatibility header needed. While this wasn't marked as private API, it wasn't documented, either. This is a prerequisite for moving QFuture to QtCore. Change-Id: I8e986e6e2a22fbe5cf08d0600ec39ae9ae993e20 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Move QtConcurrent::Exception as QException back to QtCoreMarc Mutz2012-09-281-0/+2
| | | | | | | | | Leave the old name as a deprecated typedef; adapt users. This is a prerequisite for moving QFuture back to QtCore. Change-Id: I81dcee2c7e6eb234c16f3f42e2415ca0da3dc4f8 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use standard unix mutexes on LSBHarald Fernengel2012-02-201-3/+7
| | | | | | | | LSB doesn't allow syscalls, so fall back to the normal _unix implementation Change-Id: I8aba6147da8b46e3f85b0454cf9aca219811c9fe Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* Move QtConcurrent into its own moduleLars Knoll2012-02-051-1/+6
| | | | | | | Task-number: QTBUG-20892 Change-Id: I614500aafb6428915509983608bbb0ade4e4f016 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add the new QBasicAtomicXXX implementation - no backends yetThiago Macieira2012-01-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new implementation is API- and ABI-compatible with the old implementation, provided that QBasicAtomicInt isn't used as an argument in a function call or the return value: now, QBasicAtomicInt is a typedef to QBasicAtomicInteger<int>. The new design is based on CRTP: the QGenericAtomicOps template class takes as a template parameter the derived class itself. This way, we implement a "poor man's virtual" without a virtual table and everything is inline. QGenericAtomicOps implements most of the atomics code that is repeated in many classes all over: * Acquire semantics are obtained by placing an acquire barrier after the Relaxed operation * Release semantics are obtained by placing a release barrier before the Relaxed operation * Ordered semantics are obtained by placing an ordered barrier before the Relaxed operation (either way would be fine) * fetchAndStoreRelaxed and fetchAndAddRelaxed are implemented on top of testAndSetRelaxed * ref and deref are implemented on top of fetchAndAddRelaxed It also adds load, loadAcquire, store and storeRelease: the default implementations of loadAcquire and storeRelease operate on a volatile variable and add barriers. There are no direct operators for accessing the value. Each architecture-specific implementation can override any of the functions or the memory barrier functions. It must implement at least the testAndSetRelaxed function. In addition, by specialising one template class, the implementations can allow QBasicAtomicInteger for additional types (of different sizes). At the very least, int, unsigned and pointers must be supported. Change-Id: I6da647e225bb330d3cfc16f84d0e7849dff85ec7 Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
* Copy qbasicatomic.h to qoldbasicatomic.hThiago Macieira2012-01-061-1/+3
| | | | | | Change-Id: I15df58f9dc29189419f8cbc0ce47bf11e9f17cf4 Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove symbian threading primitive.Olivier Goffart2011-10-281-5/+1
| | | | | | | | | | | Those are already outdated and do not compile anymore (QMutex has changed too much) Better to remove that dead code so it do not show up in grep anymore Change-Id: I096e7a73e23cbb77050843c2e1c10929086fdb8f Reviewed-by: Lars Knoll <lars.knoll@nokia.com> Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
* QMutex is now just a pointerOlivier Goffart2011-07-291-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | And added a POD QBasicMutex. (QBasicMutex* can safely be static_cast'ed to QMutex*) The d pointer is not anymore always a QMutexPrivate. If d == 0x0: the mutex is unlocked If d == 0x1: the mutex is locked, uncontended On linux: if d == 0x3: the mutex is locked contended, waiting on a futex If d is a pointer, it is a recursive mutex. On non-linux platforms: When a thread tries to lock a mutex for which d == 0x1, it will try to assing it a QMutexPrivated (allocated from a freelist) in order to wait for it. Change-Id: Ie1431cd9402a576fdd9a693cfd747166eebf5622 Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com> Reviewed-on: http://codereview.qt.nokia.com/2116 Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com> Reviewed-by: Olivier Goffart <olivier.goffart@nokia.com>
* Initial import from the monolithic Qt.Qt by Nokia2011-04-271-0/+41
This is the beginning of revision history for this module. If you want to look at revision history older than this, please refer to the Qt Git wiki for how to use Git history grafting. At the time of writing, this wiki is located here: http://qt.gitorious.org/qt/pages/GitIntroductionWithQt If you have already performed the grafting and you don't see any history beyond this commit, try running "git log" with the "--follow" argument. Branched from the monolithic repo, Qt master branch, at commit 896db169ea224deb96c59ce8af800d019de63f12
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-22 04:57:51 +0000