summaryrefslogtreecommitdiffstats
path: root/src/corelib/thread
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* 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>
* 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>
* 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>
* 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-30 22:47:11 +0000