summaryrefslogtreecommitdiffstats
path: root/src/corelib/thread
Commit message (Collapse)AuthorAgeFilesLines
* Replace the type-based QAtomicIntegerTraits with a size-based oneThiago Macieira2014-01-302-15/+4
| | | | | | | | This simplifies the code a lot and avoids silly mistakes where a specific integer type is missing (such as char16_t). Change-Id: Id91dfd1919e783e0a9af7bfa093ca560a01b22d1 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Centralize support for QBasicAtomic for ints and longsThiago Macieira2014-01-302-1/+39
| | | | | | | No need to redefine everywhere, since they're required to be supported. Change-Id: I2bdbbd0b0c44871e3bd0edcf0289fc58dd50ff31 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Ensure that the pointer-sized QAtomicInteger specialization existsThiago Macieira2014-01-301-1/+15
| | | | | | | | | | | | | | | | | | | This is already implemented in qatomic_x86.h, qatomic_ia64.h, qatomic_mips.h, qatomic_armv6.h, and qatomic_cxx11.h. For qatomic_msvc.h, we've just fixed it. For qatomic_gcc.h, we know that the compiler supports it, so just add it. According to the GCC manual, it might print a warning on some platforms, so we only enable that on 64-bit builds. For qatomic_unix.h, the support was missing (along with support for unsigned 32-bit), so this commits adds it. For qatomic_armv5.h, the platform does not always support 64-bit atomics, but ARMv5 cannot compile in 64-bit mode anyway. Change-Id: Ia8b3b5c641f11e5df05937fe7442be0a223174ef Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Introduce QAtomicInteger<T> and derive QAtomicInt from itThiago Macieira2014-01-302-145/+241
| | | | | | | | | | | | | | | | QAtomicInteger<T> is to QBasicAtomicInteger<T> what QAtomicInt was to QBasicAtomicInt: just a little more syntactic sugar. The Basic classes do not always have a constructor, since they depend on compiler support. The constructor is always present in the non-Basic class, at the expense of making it non-POD for C++98 code. This commit also repurposes most of QAtomicInt's documentation for QAtomicInteger. It adds only the Q_ATOMIC_INTnn_IS_SUPPORTED macro that explains whether the given type is supported on this platform. Change-Id: I58886d6fa49fea4de24015c40dae29c9fa534e00 Reviewed-by: Lars Knoll <lars.knoll@digia.com> Reviewed-by: Kurt Pattyn <pattyn.kurt@gmail.com>
* Merge remote-tracking branch 'origin/stable' into devFrederik Gladhorn2014-01-203-5/+5
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/global/qglobal.h src/corelib/tools/qstring.cpp src/gui/image/image.pri src/gui/image/qimage.cpp src/plugins/platforms/cocoa/qcocoawindow.h src/plugins/platforms/cocoa/qcocoawindow.mm src/plugins/platforms/eglfs/qeglfshooks_stub.cpp tests/auto/corelib/io/qstandardpaths/tst_qstandardpaths.cpp Change-Id: I3b9ba029c8f2263b011f204fdf68c3231c6d4ce5
| * Android: Don't register main thread on loading libraryEskil Abrahamsen Blomfeldt2014-01-163-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building with debug, all SLOT or SIGNAL macros will expand to a function call, and then function will call QThreadData::current(), which will set QCoreApplication::theMainThread if it has not already been done. Since Qt Widgets has these macros in the static initialization of the library, we would register the Android main thread as the main thread of Qt, which would mean that the actual application object was created on a different thread than the main thread. This caused warnings to appear, and also triggered a race condition which caused widget applications to sometimes show a black screen instead of content on startup when run with the OpenGL plugin. Task-number: QTBUG-35048 Change-Id: Ie8979f5e7cd5662f8d7dd276de9f94f27cc120b5 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | expand tabs and related whitespace fixes in *.{cpp,h,qdoc}Oswald Buddenhagen2014-01-131-3/+3
| | | | | | | | | | | | | | | | the diff -w for this commit is empty. Started-by: Thiago Macieira <thiago.macieira@intel.com> Change-Id: I77bb84e71c63ce75e0709e5b94bee18e3ce6ab9e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | WinRT: Clean up core event dispatcherAndrew Knight2014-01-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Move private classes in the .cpp file (they aren't needed outside) - Conform to Qt style, such as includes and braces - Use ComPtr where appropriate - Use foreach where appropriate - Remove non-functional wake/interrupt leftovers - Remove redundant timer list - Make the timer callback a static method, so it won't crash if it gets called on shutdown Task-number: QTBUG-35945 Change-Id: I5426fba2735e908a04ea60287f9936f5abde6644 Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
* | Merge remote-tracking branch 'origin/stable' into devFrederik Gladhorn2013-12-241-1/+5
|\| | | | | | | Change-Id: I2defae1904154283446b069d151c3ef57302ec7b
| * qthread_win.cpp: Fix warnings when waiting for adopted threads.Friedemann Kleint2013-12-171-1/+5
| | | | | | | | | | | | | | Task-number: QTBUG-35591 Change-Id: I63169bd8a9758a7dad33d4231d3d6c9d71c7e252 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Remove all "old atomic" code from QtThiago Macieira2013-12-104-166/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Make a nicer output when QBasicAtomicInteger is used with a wrong TThiago Macieira2013-12-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | Before, we'd get just an error message that the size of the array was negative. Now, for C++11 compilers, we get a better error message: qbasicatomic.h:117:5: error: static assertion failed: Template parameter is not a supported integer on this platform qbasicatomic.h:119:24: error: invalid use of incomplete type ‘struct QAtomicOps<long long unsigned int>’ Change-Id: I6b0792254c0dc6103a4a7608f2942d59cda07c00 Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* | Fix silly typo in a macro for QAtomicInt's constructorThiago Macieira2013-12-031-1/+1
| | | | | | | | | | | | | | | | | | The T was missing in QT_BASIC_ATOMIC_HAS_CONSTRUCTORS. This makes QAtomicInt's constructor become constexpr. Change-Id: Ibe58ff36517c5d05ce8af9c0f28169fa63521632 Reviewed-by: Marc Mutz <marc.mutz@kdab.com> Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* | Set loadAcquire() as const to fix powerpc buildFatih Aşıcı2013-11-291-2/+2
| | | | | | | | | | | | Change-Id: Ica1ea565e7eefd2ef378737eb9687ebbf4adf7b0 Fetched-from: https://bugzilla.redhat.com/attachment.cgi?id=812643 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Merge remote-tracking branch 'origin/stable' into devFrederik Gladhorn2013-11-263-5/+4
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the conflicts in msvc_nmake.cpp the ifdefs are extended since we need to support windows phone in the target branch while it is not there in the current stable branch (as of Qt 5.2). Conflicts: configure qmake/generators/win32/msvc_nmake.cpp src/3rdparty/angle/src/libEGL/Surface.cpp src/angle/src/common/common.pri src/corelib/global/qglobal.h src/corelib/io/qstandardpaths.cpp src/plugins/platforms/qnx/qqnxintegration.cpp src/plugins/platforms/qnx/qqnxscreeneventhandler.h src/plugins/platforms/xcb/qglxintegration.h src/widgets/kernel/win.pri tests/auto/corelib/thread/qreadwritelock/tst_qreadwritelock.cpp tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp tests/auto/gui/text/qtextdocument/tst_qtextdocument.cpp tools/configure/configureapp.cpp Change-Id: I00b579eefebaf61d26ab9b00046d2b5bd5958812
| * Windows: Close handle to thread checking for adopted threads.Friedemann Kleint2013-11-261-1/+1
| | | | | | | | | | | | | | | | | | | | Task-number: QTBUG-34840 [ChangeLog][QtCore][QThread][Windows][QTBUG-34840] Fix handle leak. Change-Id: I537c1c81a43907f01a81be740746582266969c6f Reviewed-by: Andy Shaw <andy.shaw@digia.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
| * QBasicAtomicInt: fix wrong comment about non-atomic APIDavid Faure2013-11-021-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | The public documentation for load() and store() says it's atomic, and it is: * using _q_value.store(newValue, std::memory_order_relaxed) in the C++11 implementation * using a simple assignment otherwise, which is atomic (and relaxed, no memory barriers) on all the existing C++ ABIs. Change-Id: I40faa47120163225bd11c3a32514ac97ef8bbbd4 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
| * Doc: Fix miscellaneous typosSze Howe Koh2013-10-301-1/+1
| | | | | | | | | | | | Change-Id: Iaf0dd8974c3ad78beffa995c596a76fb3e4cceab Reviewed-by: Jerome Pasion <jerome.pasion@digia.com> Reviewed-by: Kurt Pattyn <pattyn.kurt@gmail.com>
* | QThreadPool: fix race at time of thread expiry.David Faure2013-10-312-18/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current synchronization mechanism was racy: decrementing waitingThreads and then hoping that the wakeOne will wake a thread before its expiry timeout happens. In other words, on timeout, a just-assigned task would never run. And then no other task would run, if maxThreadCount is reached. Fixed by using a queue of waiting threads (rather than just a count), and by moving the wait condition into the thread itself, so we know precisely which one we're waking up, and we can remove it from the set of waiting threads before waking it up, and therefore it can determine on wakeup whether it has work to do (caller removed it from the queue) or it expired (it's still in the queue). This is reliable, whereas the return value from QWaitCondition::wait isn't reliable, when the main thread has already decided that this thread has work to do. Task-number: QTBUG-3786 Change-Id: I1eac5d6c309daed7f483ac7a8074297bfda6ee32 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Merge remote-tracking branch 'origin/stable' into devFrederik Gladhorn2013-10-241-14/+15
|\| | | | | | | Change-Id: Ie56539b2e0be611a363b5f15ae5412a78d6945a2
| * Doc: Update, and reduce duplication of, QThread-related infoSze Howe Koh2013-10-211-14/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added/Changed: - Move content from the Thread Basics overview to the QThread class ref - Rephrase bits for clarity - Use more links Removed: - (threads-basics.qdoc) Warning against moveToThread(this): This usage came about when people tried to add slots to a QThread subclass. This patch adds a warning against the root cause. - (threads-basics.qdoc) Note on sleep() et al.: They were made public in Qt 5.0. - (threads-basics.qdoc) The strategy for managing member variables: Sounds error-prone. Pushing results through signals is safer. - (qthread.cpp) The note about GUI classes: Irrelevant to QThread, and it's already mentioned elsewhere. Change-Id: I6bc53cc22b929523f9976d2b920f94c02bd7273e Reviewed-by: Geir Vattekar <geir.vattekar@digia.com> Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* | Merge remote-tracking branch 'origin/stable' into devFrederik Gladhorn2013-10-1112-98/+123
|\| | | | | | | Change-Id: Ib8cfeee7d9ca15e8ad520e428b72c200827a8628
| * Reorder the members in QThreadData to avoid padding holesThiago Macieira2013-10-082-10/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, this struct had size 104 and a total of 21 padding bytes. Now it's down to 88 bytes and only 5 bytes of padding. pahole report on a 64-bit system: class QAtomicInt _ref; /* 0 4 */ /* XXX 4 bytes hole, try to pack */ public: class QThread * thread; /* 8 8 */ HANDLE threadId; /* 16 8 */ bool quitNow; /* 24 1 */ /* XXX 3 bytes hole, try to pack */ int loopLevel; /* 28 4 */ class QAtomicPointer<QAbstractEventDispatcher> eventDispatcher; /* 32 8 */ class QStack<QEventLoop*> eventLoops; /* 40 8 */ /* --- cacheline 1 boundary (64 bytes) --- */ class QPostEventList postEventList; /* 48 32 */ bool canWait; /* 80 1 */ /* XXX 7 bytes hole, try to pack */ class QVector<void*> tls; /* 88 8 */ bool isAdopted; /* 96 1 */ /* size: 104, cachelines: 2, members: 11 */ /* sum members: 90, holes: 3, sum holes: 14 */ /* padding: 7 */ Change-Id: I1fc88e0b312f38eccdea440734fd37e0519285a2 Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
| * Doc: Adding mark-up to boolean default values.Jerome Pasion2013-10-0811-89/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Default values should have mark-up to denote that they are code. This commit changes: -"property is true" to "property is \c true". -"Returns true" to "Returns \c true". -"property is false" to "property is \c false". -"returns true" to "returns \c true". -"returns false" to "returns \c false". src/3rdparty and non-documentation instances were ignored. Task-number: QTBUG-33360 Change-Id: Ie87eaa57af947caa1230602b61c5c46292a4cf4e Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
| * QObject: use per-thread storage for qFlagLocation()Marc Mutz2013-10-051-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qFlagLocation() uses a global char* array to transport source location information from the connect() side to the metaobject side. The size of the array is 2 (two), which just about suffices for a single connect() statement. Obviously, if more than one thread makes a (_any_) connection at the same time, the data is useless and, worse, there's a data race. The non-reentrancy of qFlagLocations() cannot and need not be fixed, but use a per-thread flagged_locations array in QThreadData so threads don't disturb each other. Task-number: QTBUG-3680 Change-Id: If1797c60751f551694def69afee6fbe295bbe2d2 Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* | add WinRT event dispatcherOliver Wolff2013-09-261-0/+8
| | | | | | | | | | | | Change-Id: I40b3f896b89b99e271e1a5ca625a5193f4a7f59e Done-with: Kamil Trzcinski Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* | threading support for winrtKamil Trzcinski2013-09-265-2/+175
|/ | | | | | Change-Id: Ife296e15ddf727c3f53ab3d3d84634b5c7bbf85c Done-with: Maurice Kalinowski Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* QFutureInterface: wrap a pair of {release,reserve}Thread() calls with RAIIMarc Mutz2013-09-211-3/+14
| | | | | | | | | | | | Rationale: a wait on a condition-variable is usually a cancellation point. On Posix, and probably in C++ at some point, a thread cancellation is done by (a kind of) exception unwinding the stack. To ensure that we call reserveThread() in all cases, wrap the function pair in a RAII class. Even if we currently don't seem to support exceptions in QtCore, this is low-hanging fruit, and no worse than what we had before. Change-Id: Ifb0f428ea50f9ac12be14e620615f46e00d3dd91 Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
* Merge "Merge branch 'stable' into dev" into refs/staging/devSergio Ahumada2013-09-213-5/+4
|\
| * Merge branch 'stable' into devSergio Ahumada2013-09-213-5/+4
| |\ | | | | | | | | | Change-Id: I37d85631ab1165ab91457d8880c4da907a9df73b
| | * Doc: Remove duplicated Qt Concurrent overviewSze Howe Koh2013-09-163-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | - The "Concurrent Programming" page is an exact duplicate of the Qt Concurrent module landing page. - The "qtconcurrent intro" target is not referenced anywhere. Change-Id: Ice9b4360783013fe972258ca54a0004be43b8766 Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
* | | Fix some doc errors.Frederik Gladhorn2013-09-212-2/+2
|/ / | | | | | | | | | | | | Change-Id: Ib874d7e9671d9cee75fe41f4dac5d0de7b09245e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Topi Reiniö <topi.reinio@digia.com> Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
* | QMutex: fix race on 'owner' in the recursive caseMarc Mutz2013-09-211-4/+11
| | | | | | | | | | | | | | | | | | | | | | The read from 'owner' for comparison with 'self' in QRecursiveMutexPrivate::lock() is not synchronized with the write to 'owner' in the same function further down, and neither operation is atomic. Fix by making 'owner' an atomic pointer. Change-Id: I186b88575589da0dce5827a1e17ceb4ce599ed02 Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* | QFutureInterface: remove unused member variable 'pendingResults'Marc Mutz2013-09-202-2/+1
| | | | | | | | | | Change-Id: I059580831ed29a53186272283aa7695c57539eed Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* | Don't use ARMv5/6/7 atomics on 64-bit ARM, as they are AArch32 specificTor Arne Vestbø2013-09-161-3/+3
| | | | | | | | | | Change-Id: I0c359e62a8cbf560691019187f316561bddbee52 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-17 21:32:26 +0000