summaryrefslogtreecommitdiffstats
path: root/src/corelib/thread
Commit message (Collapse)AuthorAgeFilesLines
* Add an advisory interruption mechanism to QThread.Corentin Jabot2013-09-055-1/+67
| | | | | | | | | | | | | | To ease interruption of long running tasks, a new method QThread::setInterruptionRequested() can be called. The task can check QThread::isInterruptionRequested() and act upon it by stopping itself. These methods are designed to replace the use of a global variable and other hacky ways to stop a task running in another thread. Change-Id: I17622dd60d2262078210e7e4294ad6c53a6dc179 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix typo in qwaitcondition_unix.cppDavid Faure2013-09-021-1/+1
| | | | | Change-Id: Ifc1fdaaa05275b6f68a868a2fc8ccc332e5355ce Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* Move the creation of QElapsedTimer out of the inner function in QMutexThiago Macieira2013-08-271-21/+5
| | | | | | | Makes it possible for QElapsedTimer to be non-POD. Change-Id: I5ffc59c7a93c187a4a814e6959f8383fa8d4cc44 Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
* QThreadPool: fix counting of waiting threadsDavid Faure2013-08-241-2/+8
| | | | | | | | | | | | | | | | | | QTBUG-21051 has a testcase where activeThreadCount() could actually end up at -1 (converted to an autotest in this commit). The reason was: start() calls tryStart() which returns false due to too many active threads (reserveThread() causes this), so it calls enqueueTask() - which actually wakes up the waiting thread, but it didn't decrement the number of waiting threads. Note that tryStart() is "if I can grab a waiting thread, enqueue task and wake it" while start(), in case tryStart() fails, wants to "enqueue, and then if I can grab a waiting thread, wake it". This is why enqueue shouldn't wake; waking must happen only if we can grab a thread (d->waitingThreads > 0). Task-number: QTBUG-21051 Change-Id: I3d98337103031c9bdf0bf365295f245be0c66aa7 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QThreadPool: fix data races in activeThreadCount()David Faure2013-08-211-5/+3
| | | | | | | | | | | | | | | | | | Rather than trying to make it lock-free (which requires double-bookkeeping of 4 atomic ints!), just lock the mutex before calling it. tst_bench_qthreadpool shows no difference whatsoever between the two solutions, I get 0.005 msecs per iteration in startRunnables(). Of course looping over calls to activeThreadCount() is a bit slower, from 0.0002 msecs per iteration to 0.00027 msecs, i.e. 35% more. But polling activeThreadCount() from the app is a really wrong thing to do anyway, this benchmark was just for my own curiosity about the price of a mutex in a function that sums up 4 ints. What matters is start() performance, which is unchanged (0.00007 msecs is just noise compared to a 0.005 total, that's 1.4%). Change-Id: I993444eef8bc68eff9badd581fae3626dfd1cc6d Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* QThreadPool: fix typosDavid Faure2013-08-211-10/+10
| | | | | | Task-number: QTBUG-31919 Change-Id: I2718566595622895f182191b5693e91c1ab1e7d0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QThreadPool - Add method clear() to remove queued QRunnable.Corentin Jabot2013-08-163-0/+30
| | | | | | | | | | | | | | QThreadPool::clear() method removes all queued QRunnable. When a large number of long-running tasks are queud in a QThreadPool its destruction, which calls waitForDone(), can be quite long. QThreadPool:clear() removes (and deletes when appropriate) all QRunnable that have yet to be started from the queue enabling a faster interruption. Change-Id: Ie5d6028ad3cfe7e439d1db068c8d0936ff818db9 Reviewed-by: David Faure <david.faure@kdab.com>
* Further followup to Q_OS_MACX changes.Jake Petroules2013-06-241-2/+2
| | | | | | | | Flip !Q_OS_IOS conditions to Q_OS_MACX where it seems appropriate, remove a redundant condition in qtextcodec_p.h. Change-Id: I21c8c0c490f1eb4a9337a7f2f3e907c125489438 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* Remove use of 'register' from Qt.Stephen Kelly2013-06-172-3/+3
| | | | | | | | | | It is deprecated and clang is starting to warn about it. Patch mostly generated by clang itself, with some careful grep and sed for the platform-specific parts. Change-Id: I8058e6db0f1b41b33a9e8f17a712739159982450 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix crash when re-creating QThreadData after initially destroying itTor Arne Vestbø2013-06-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We destroy the thread data for the main thread when the QCoreApplication is destructed, and then delete the pthread key for the thread data in the global static destructor function 'destroy_current_thread_data_key'. The user may have its own Q_DESTRUCTOR_FUNCTION though, which may or may not run after we've destroyed the key. If it runs after we've destroyed the key, we'll end up trying to re-create the tread-data, as expected, but set_thread_data() will fail to persist it, as pthread_setspecific is called with an invalid key. The result is an infinite recursion: ... 6 in QThreadData::current () at qthread_unix.cpp:216 7 in QObject::QObject (this=0x48e1b30, dd=@0x48e1b40, parent=0x0) at qobject.cpp:703 8 in QThread::QThread (this=0x48e1b30, dd=@0x48e1b40, parent=0x0) at qthread.cpp:396 9 in QAdoptedThread::QAdoptedThread (this=0x48e1b30, data=0x48e1af0) at qthread.cpp:120 10 in QAdoptedThread::QAdoptedThread (this=0x48e1b30, data=0x48e1af0) at qthread.cpp:130 11 in QThreadData::current () at qthread_unix.cpp:219 12 in QObject::QObject (this=0x48e1a20, dd=@0x48e1a30, parent=0x0) at qobject.cpp:703 ... To solve this, we reset current_thread_data_once when destroying the key, so that subsequent calls to pthread_once to potentially create the key will call create_current_thread_data_key once more. This means we'll leak the key for this particular use-case, since we don't end up calling pthread_key_delete a second time, but this leak is small and happens typically only for a short duration during application shutdown. Change-Id: I580484a3239849e891172e24e7f77b75afd2c51b Reviewed-by: Olivier Goffart <ogoffart@woboq.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QThreadPool: Fix regression from Qt 4 in dealing with priority startsThiago Macieira2013-05-201-1/+1
| | | | | | | | | | | | The optimisation done in cbaf52b09971edf6f3e1458f7dd677b80a1568ed for Qt 5.0 got the order wrong of the comparison. The queue must be sorted in decreasing priority order. But since higher numbers mean higher priority, that means the queue must be sorted in decreasing priority number order. Task-number: QTBUG-29163 Change-Id: Iaf3424b9bb445bf5c71518927f37253cead454f3 Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
* Fix possible race in QMutexOlivier Goffart2013-04-291-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As described in the QTBUG-30872, there may be a race condition involving 3 threads fighting for a mutex. I am surprised it was not caught before despite all the Q_ASSERT and the stress test in tst_qmutex. We do not need to call store(0) because the unlocking thread will eventually remove the BigNumber flag. And perhaps it even did it already, and another thread has incremented waiters (hence the Q_ASSERT is wrong) Here is a paste of part of the description from the bug report: --- many threads, one of them is ready to release mutex, while at least two other trying to acquire it d->waiters is 0 Thread 1 release mutex in unlockInternal: if (d->waiters.fetchAndAddRelease(-QMutexPrivate::BigNumber) == 0) d->waiters is now -QMutexPrivate::BigNumber Thread 2 try to acquire mutex in lockInternal: old_waiters = d->waiters.load(); if (old_waiters == -QMutexPrivate::BigNumber) { if (d_ptr.testAndSetAcquire(d, dummyLocked())) { It acquire 'about to release mutex' by changing d to dummyLocked Thread 1 continue release procedure: d->derefWaiters(0); d->waiters is now back to 0 Thread 3 try to acquire mutex in lockInternal: while (!d->waiters.testAndSetRelaxed(old_waiters, old_waiters + 1)); d->waiters is now 1 Thread 2 continue its dummy lock: d->waiters.store(0); d->waiters is force to 0 Thread 3 continue wait procedure but it realize that mutex was already unlocked so decrease back waiters if (d != d_ptr.loadAcquire()) { if (old_waiters != QMutexPrivate::BigNumber) { d->waiters.deref(); d->waiters became negative value of -1 Neither thread need internal data so it is released back to pool The waiters counter in released internal structure is still -1 --- Change-Id: I1b22555db764482775db6e64a8c9ffa9e1ab0cf6 Task-number: QTBUG-30872 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* fix namespaced buildOswald Buddenhagen2013-04-251-2/+2
| | | | | Change-Id: I9d0a3cb08de5e91807da7f0358c83b6693ebd1ea Reviewed-by: hjk <hjk121@nokiamail.com>
* Document that the mutex passed to QWaitCondition::wait must be lockedThiago Macieira2013-04-221-2/+2
| | | | | | | | | Simply say that the behaviour is undefined if you don't do what you must do. I don't want to introduce a check: it can't be done reliably anyway. Task-number: QTBUG-30806 Change-Id: Iba1bbbdfe62ffcb133f9c52215efdcc0ee7bd9bd Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* Fix C++11 support in clang prior to 3.2Jan Kundrát2013-04-121-2/+2
| | | | | | | | | | | | | The comments in this file suggested that the bug was only present in clang/3.1. However, qRegisterMetaType was failing even on clang 3.2 ("tags/RELEASE_32/final"). The clang's bugzilla says [1] that the problem was fixed two days before the release of 3.2, but apparently it didn't make it to the release branch. [1] http://llvm.org/bugs/show_bug.cgi?id=13470 Change-Id: I37db8f6f6b22ab939110e79240d92313c1786d6a Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* Use Bionic's __pthread_cond_timedwait_relativeThiago Macieira2013-04-021-0/+15
| | | | | | | | | | | | | The Linux futex interface uses relative timeouts anyway, so this avoids a double round-trip through clock_gettime: once in Qt code to calculate absolute from relative and once in libc for reversing. Glibc does not offer such a function because its pthread_cond objects use a kernel interface that works on absolute times. Change-Id: I8fbcd3f73d4364a16716b0eea17e8f5f9ab5cd05 Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add a function to do the relative waits, simplifying the code a littleThiago Macieira2013-04-021-3/+8
| | | | | | | More to come. Change-Id: I108f23e94c322ad4e1466ff69100ad6af91d95e9 Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
* Fix build on Android: libpthread is deficient and lacks functionsThiago Macieira2013-04-021-1/+1
| | | | | | | | | | | Even if the monotonic clock is available, Android's Bionic lacks the pthread_condattr_setclock function, so we can't tell it to use the monotonic clock. Task-number: QTBUG-30450 Change-Id: I4f53708b1e834ff5d9462b3bf778b96c22662a04 Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com> Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
* Fix race condition in QThread::setPriorityDavid Faure2013-03-234-41/+42
| | | | | | | | | | | | | The value of priority was read without the mutex locked, from within the thread. Had to extract a QThreadPrivate::setPriority method so that it can be called with the mutex already locked. So if the main thread calls setPriority while the thread is starting, it will be either be before or after the "re-set priority" code at thread startup, but at least not in the middle of it. Change-Id: I7a054f68623f61482c749274da66f3b2dcd8bcee Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* QThread: fix race when setting the eventDispatcherDavid Faure2013-03-224-15/+18
| | | | | | | Use QAtomicPointer to make this thread-safe. Change-Id: If71f204699fcefabdb59bd26342d777d1cc9e2a7 Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* QThreadDataPrivate: fix data race on canWait boolean.David Faure2013-03-221-0/+6
| | | | | | | | postEvent() accesses it with the postEventList mutex locked, but processEvent() was checking it without any mutex locked. Change-Id: I31bbb50f7a1c337067b8e3de16ee7cd11400b517 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Whitespace cleanup: remove trailing whitespaceAxel Waggershauser2013-03-1612-24/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | Remove all trailing whitespace from the following list of files: *.cpp *.h *.conf *.qdoc *.pro *.pri *.mm *.rc *.pl *.qps *.xpm *.txt *README excluding 3rdparty, test-data and auto generated code. Note A): the only non 3rdparty c++-files that still have trailing whitespace after this change are: * src/corelib/codecs/cp949codetbl_p.h * src/corelib/codecs/qjpunicode.cpp * src/corelib/codecs/qbig5codec.cpp * src/corelib/xml/qxmlstream_p.h * src/tools/qdoc/qmlparser/qqmljsgrammar.cpp * src/tools/uic/ui4.cpp * tests/auto/other/qtokenautomaton/tokenizers/* * tests/benchmarks/corelib/tools/qstring/data.cpp * util/lexgen/tokenizer.cpp Note B): in about 30 files some overlapping 'leading tab' and 'TAB character in non-leading whitespace' issues have been fixed to make the sanity bot happy. Plus some general ws-fixes here and there as asked for during review. Change-Id: Ia713113c34d82442d6ce4d93d8b1cf545075d11d Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
* simplify/fix QT_BOOTSTRAPPED-related #ifdefsOswald Buddenhagen2013-03-141-1/+1
| | | | | | | | | | don't test for building specific tools when we actually only want to know whether we are bootstrapping. so far, this was only redundant; with the upcoming change of not bootstrapping unnecessarily it would be outright broken. Change-Id: I7600d8ebb14a4194640c50035e35a04263f2ccce Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.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>
* Clear the current thread data for the main threadThiago Macieira2013-03-054-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | This avoids crashes accessing deleted memory when creating a QObject after the last QObject had been deleted, like a qDebug() in global destructors. ==41000== Invalid read of size 4 ==41000== at 0x5F01ED5: bool QBasicAtomicOps<4>::ref<int>(int&) (qatomic_x86.h:208) ==41000== by 0x5F01309: QBasicAtomicInteger<int>::ref() (qbasicatomic.h:147) ==41000== by 0x5F24051: QThreadData::ref() (qthread.cpp:100) ==41000== by 0x614A984: QObject::QObject(QObject*) (qobject.cpp:681) ==41000== Address 0x6ee73f0 is 0 bytes inside a block of size 152 free'd ==41000== at 0x4A0736C: operator delete(void*) (vg_replace_malloc.c:480) ==41000== by 0x5F240BF: QThreadData::deref() (qthread.cpp:109) ==41000== by 0x6113F6B: QCoreApplicationData::~QCoreApplicationData() (qcoreapplication.cpp:268) The comment right above the change in qthread.cpp looks eerily similar to the problem I'm trying to fix. However, the actual change that introduced the change is not in the Qt public history, so we can't know for sure what the problem was then. Change-Id: I0dba895b041fe6cf81e6f8939ca85035cd00aad1 Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* Introducing the Qt Android portPaul Olav Tvete2013-03-051-4/+4
| | | | | | | | | | | | | | | | | | | | | Based on the Necessitas project by Bogdan Vatra. Contributors to the Qt5 project: BogDan Vatra <bogdan@kde.org> Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com> hjk <hjk121@nokiamail.com> Oswald Buddenhagen <oswald.buddenhagen@digia.com> Paul Olav Tvete <paul.tvete@digia.com> Robin Burchell <robin+qt@viroteck.net> Samuel Rødal <samuel.rodal@digia.com> Yoann Lopes <yoann.lopes@digia.com> The full history of the Qt5 port can be found in refs/old-heads/android, SHA-1 249ca9ca2c7d876b91b31df9434dde47f9065d0d Change-Id: Iff1a7b2dbb707c986f2639e65e39ed8f22430120 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Mark all qtbase headers that aren't cleanThiago Macieira2013-03-032-0/+2
| | | | | | | | | | | | | | | | QtCore has a few headers that, though public, aren't meant to be included directly. Those are the atomic headers, the three _impl.h headers and qt_windows.h. QtGui includes two OpenGL headers that don't compile on their own. Other libraries should not have headers like that (but they do, something we need to fix eventually). Change-Id: I55e4eb057748f47df927ee618f9409acbc189cc1 Reviewed-by: Sean Harmer <sean.harmer@kdab.com> Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Merge remote-tracking branch 'origin/stable' into devFrederik Gladhorn2013-02-141-38/+24
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/concurrent/doc/qtconcurrent.qdocconf src/corelib/doc/qtcore.qdocconf src/corelib/global/qglobal.h src/dbus/doc/qtdbus.qdocconf src/dbus/qdbusmessage.h src/gui/doc/qtgui.qdocconf src/gui/image/qimagereader.cpp src/network/doc/qtnetwork.qdocconf src/opengl/doc/qtopengl.qdocconf src/opengl/qgl.h src/plugins/platforms/windows/qwindowswindow.cpp src/printsupport/doc/qtprintsupport.qdocconf src/sql/doc/qtsql.qdocconf src/testlib/doc/qttestlib.qdocconf src/tools/qdoc/doc/config/qt-cpp-ignore.qdocconf src/widgets/doc/qtwidgets.qdocconf src/xml/doc/qtxml.qdocconf Change-Id: Ie9a1fa2cc44bec22a0b942e817a1095ca3414629
| * QThread documentation: do not discourage the reimplementation of QThreadOlivier Goffart2013-02-041-38/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new QThread documentation now really discourage to reimplement QThread. But in fact, there are many cases where it is perfectly fine. And the example given is even a case where using worker object is wrong. The examle even contains a leak since the thread will never stop and will even leak. This changes put back some sentences from before commit d4ad9dbbf96884c0899e8f8116a8a056facd52d5. The sample code has been re-writen. Notice how reimpementing run takes less lines of code, less runtime overhead, no leaks, and also is more complete than the previous example. Change-Id: I6cb80826e917dd5ce442ccad2572ec692ccb25ab Reviewed-by: Andre Somers <andre@familiesomers.nl> Reviewed-by: Geir Vattekar <geir.vattekar@digia.com> Reviewed-by: Debao Zhang <hello@debao.me> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Added support for multicore CPUs for INTEGRITY (V10+) target.Florian Behrens2013-01-301-0/+7
| | | | | | | | | | | | | | QThread::idealThreadCount returns now the number of cores. Change-Id: Idc23fc3c257165f6a63c6a7686a57a4fe76f6413 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Remove QT_{BEGIN,END}_HEADER macro usageSergio Ahumada2013-01-2918-63/+0
| | | | | | | | | | | | | | | | | | | | | | The macro was made empty in ba3dc5f3b56d1fab6fe37fe7ae08096d7dc68bcb and is no longer necessary or used. Discussed-on: http://lists.qt-project.org/pipermail/development/2013-January/009284.html Change-Id: Id2bb2e2cabde059305d4af5f12593344ba30f001 Reviewed-by: Laszlo Papp <lpapp@kde.org> Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
* | Set some attributes on pthread condattrsThiago Macieira2013-01-283-14/+52
| | | | | | | | | | | | | | | | | | Make them use the monotonic clock if that's available. On Mac, the monotonic clock is not available -- Qt fakes monotonic support by using the Mach timebase -- so we need to use gettimeofday. Change-Id: Iaea0b0c0de1b4802780e2476dc3643b703db392c Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* | Merge "Merge remote-tracking branch 'origin/stable' into dev" into ↵Frederik Gladhorn2013-01-2348-48/+48
|\| | | | | | | refs/staging/dev
| * Update copyright year in Digia's license headersSergio Ahumada2013-01-1848-48/+48
| | | | | | | | | | Change-Id: Ic804938fc352291d011800d21e549c10acac66fb Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* | Use sched_get_priority_* functions only for SCHED_RR and SCHED_FIFOPasi Petäjäjärvi2013-01-231-2/+14
|/ | | | | | | | | In VxWorks set default values for scheduling priority to use SCHED_FIFO_HIGH_PRI and SCHED_FIFO_LOW_PRI defines for other scheduling policies than SCHED_RR or SCHED_FIFO. Change-Id: If78b84cd9ef94d7712206e9442e96cdba727610f Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
* Replace macro qdoc with Q_QDOCDebao Zhang2013-01-086-12/+12
| | | | | | | | Both qdoc and Q_QDOC are used in source code, which looks not good. Change-Id: I4f3a71670278b0758d92bfa5db086a07e1b1acfd Reviewed-by: hjk <qthjk@ovi.com> Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
* Don't use MPProcessorsScheduled on Mac OS XThiago Macieira2012-12-281-5/+2
| | | | | | | | | | | It's deprecated and it's not available on iOS anyway. The recommended way of getting the number of processors online is via sysctl or sysconf (both of which are just slightly below). qthread_unix.cpp:397:13: error: 'MPProcessorsScheduled' is deprecated: first deprecated in Mac OS X 10.7 [-Werror,-Wdeprecated-declarations] Change-Id: I4bf60985fbde155b78b840f3de3ff0a142b78b19 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* Fix QMutex::tryLock with negative valuesThiago Macieira2012-12-231-3/+2
| | | | | | | | | | | | The Linux futex implementation had a Q_ASSERT for positive values, but the documentation says that negative values should be interpreted as infinite (equal to lock()). Test that too. Change-Id: I2f96a502d672732781e88e49797756ca9a809121 Reviewed-by: David Faure (KDE) <faure@kde.org> Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* Fix some typosSergio Ahumada2012-12-211-2/+2
| | | | | Change-Id: I4e8d9bd8ea66ec810e4f1fbfd8ddbf25c4b3d980 Reviewed-by: Mitch Curtis <mitch.curtis@digia.com>
* Review of documentation.Michele Caini2012-12-201-1/+1
| | | | | | | Terms fixing. Changes apply to Qt5 as well as Qt4. Change-Id: Ibb31ab0d68c62f3feb63722dd967932c2543fa37 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Similarly to the 797f3c0a01e9, fix qbasicatomic.h inclusionThiago Macieira2012-12-191-2/+2
| | | | | | | | qatomic.h includes qbasicatomic.h, so break the cyclic inclusion problem. Change-Id: If72bacbcfa36993336786f31e8980fbd43df8bdc Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* Document the new load / store methods in QAtomic{Int,Pointer}Thiago Macieira2012-12-122-0/+86
| | | | | | | Task-number: QTBUG-24627 Change-Id: Iaa2573aa8f0f36cac81efa73020c2f365bfcba53 Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* Doc: Remove the mention of non-atomic convenience operators in QAtomicThiago Macieira2012-12-121-12/+0
| | | | | | | | | | For two reasons: 1) those operators are gone and 2) the ones that remain are atomic. Task-number: QTBUG-28532 Task-number: QTBUG-24627 Change-Id: I1e9d1b076d923546c1ee3d45f312066590f97416 Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* QtBase: Doc: Fix links to STL-style iteratorsDavid Schulz2012-12-061-4/+4
| | | | | Change-Id: I2822c2a7e9bfc1949c20ff81e08961f641e961fb Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
* Fixed compatibility problem with ExceptionhandlingHolger Ihrig2012-11-301-1/+1
| | | | | | | | | | | When QtBase is compiled with Exeptions it was incompatible with the other modules compiled with QT_NO_EXCEPTIONS. This resulted in a linker error with ExceptionStore::throwPossibleExceptions, one time returning a const value and the other time without it Change-Id: I0e0dff61aceeec3cfde119b00ed15f3aa9f12659 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Document how to name threads.Mitch Curtis2012-11-281-0/+8
| | | | | | Change-Id: If7a7bf4f54509ebb86ce394d8bb5a7748ef419d5 Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com> Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
* QtCore: Make more signals private.Stephen Kelly2012-11-283-7/+15
| | | | | | Change-Id: Ida190e8b9c1ff47a6f54a5bf68673ab50a2f1bfe Reviewed-by: Olivier Goffart <ogoffart@woboq.com> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
* Fix race condition on d->state, by locking the mutex first.David Faure2012-11-231-3/+9
| | | | | | | | Detected by helgrind ./tst_qurl testThreads Change-Id: I0fe01153cd119741ce8a2bfe7dddead7c6ebf0b0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
* Fix QMutex::tryLock timeout computation on LinuxOlivier Goffart2012-11-161-2/+2
| | | | | | | | | | | The timeout is in millisecond. So we just need to divide by 1000 to get the number of seconds Regression introduced in f587e8f4fd670f11fa1e878c1015d7241033559a Reported in the comments of QTBUG-24795 Change-Id: Id16e05e7d04d33605860926f7516d14cdefd6a36 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QFutureInterface: Remove unused functionOrgad Shaneh2012-11-082-6/+0
| | | | | | | | Following 731ba8ed08f80644b403556638c7f6229e678ebe this function is not used anymore Change-Id: Id908931b4b21c825bd80a4f03790630818c73c07 Reviewed-by: Christian Stromme <christian.stromme@digia.com>