| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Change-Id: Ifc1fdaaa05275b6f68a868a2fc8ccc332e5355ce
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
|
|
|
|
|
|
| |
Makes it possible for QElapsedTimer to be non-POD.
Change-Id: I5ffc59c7a93c187a4a814e6959f8383fa8d4cc44
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
Task-number: QTBUG-31919
Change-Id: I2718566595622895f182191b5693e91c1ab1e7d0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Change-Id: I9d0a3cb08de5e91807da7f0358c83b6693ebd1ea
Reviewed-by: hjk <hjk121@nokiamail.com>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
More to come.
Change-Id: I108f23e94c322ad4e1466ff69100ad6af91d95e9
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
Use QAtomicPointer to make this thread-safe.
Change-Id: If71f204699fcefabdb59bd26342d777d1cc9e2a7
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| | |
QThread::idealThreadCount returns now the number of cores.
Change-Id: Idc23fc3c257165f6a63c6a7686a57a4fe76f6413
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\|
| |
| |
| | |
refs/staging/dev
|
| |
| |
| |
| |
| | |
Change-Id: Ic804938fc352291d011800d21e549c10acac66fb
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
|
|/
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Change-Id: I4e8d9bd8ea66ec810e4f1fbfd8ddbf25c4b3d980
Reviewed-by: Mitch Curtis <mitch.curtis@digia.com>
|
|
|
|
|
|
|
| |
Terms fixing. Changes apply to Qt5 as well as Qt4.
Change-Id: Ibb31ab0d68c62f3feb63722dd967932c2543fa37
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
| |
qatomic.h includes qbasicatomic.h, so break the cyclic inclusion
problem.
Change-Id: If72bacbcfa36993336786f31e8980fbd43df8bdc
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
|
|
|
|
|
|
| |
Task-number: QTBUG-24627
Change-Id: Iaa2573aa8f0f36cac81efa73020c2f365bfcba53
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Change-Id: I2822c2a7e9bfc1949c20ff81e08961f641e961fb
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
Change-Id: If7a7bf4f54509ebb86ce394d8bb5a7748ef419d5
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
|
|
|
|
|
|
| |
Change-Id: Ida190e8b9c1ff47a6f54a5bf68673ab50a2f1bfe
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
Following 731ba8ed08f80644b403556638c7f6229e678ebe this function is
not used anymore
Change-Id: Id908931b4b21c825bd80a4f03790630818c73c07
Reviewed-by: Christian Stromme <christian.stromme@digia.com>
|