[ChangeLog][QtCore][QThreadPool] Added QThreadPool::cancel() which allows
removing from the job queue a job that hasn't been started yet.
Change-Id: Ib8f1c1f32a34f5eec8338c641d820b928e470164
Reviewed-by: Nick Shaforostoff <shafff@ukr.net>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Change-Id: I91ff06644e8047c2ca483f9768b46c1372eb6171
Reviewed-by: Martin Smith <martin.smith@digia.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Benign, but easy to avoid by using the same pattern as in clear().
Change-Id: Ie382313343385f0709519b232a7d58dd8181b8de
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Background:
It is often necessary/advisable to schedule tasks on thread pools !=
globalInstance(). As Herb Sutter writes in
http://www.drdobbs.com/parallel/use-thread-pools-correctly-keep-tasks-sh/216500409
and the Qt Training Material stresses, tasks you schedule on a (global)
thread pool should be non-blocking, which currently rules out using any of
the QtConcurrent functions for, say, file I/O.
Nonetheless it's often convenient to have thread pools also for file I/O, as
the thumbnail viewer exercise in the Qt Training Material shows. In this
case, you'd use a dedicated thead pool, leaving the global thread pool for
CPU-bound tasks.
Yet, none of the QtConcurrent functions allow to pick the QThreadPool
instance on which to schedule the work created with them.
This patch prepares for them to do so.
This is the first part of the forward-port of
https://qt.gitorious.org/qt/qt/merge_requests/1281.
Implement by using a new QThreadPool* member that defaults to nullptr,
and adding setThreadPool to set this member, then using it in lieu of
QThreadPool::globalInstance() everywhere.
I chose to leave m_pool == nullptr to mean globalInstance() to avoid
creating the global instance whenever a QFuture is created, even if the
future represents the result of a calculation not run on the global thread
pool.
[ChangeLog][QtCore][QFuture] Can now be used with any QThreadPool, not
just globalInstance().
Task-number: QTBUG-17220
Change-Id: I4e1dc18d55cf60141b2fa3d14e2d44a3e9e74858
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
The combination of these unstable tests makes it very
hard to get changes through the CI system due to the
unrelated test failures.
Skip the following test functions:
tst_QIODevice::unget QTBUG-39983 (Mac)
tst_QThreadPool:expiryTimeoutRace QTBUG-3786 (Windows)
tst_QLocalSocket::processConnection QTBUG-39986 (Mac)
tst_QTcpServer::adressReusable QTBUG-39985 (Linux)
Change-Id: I96559bea0d437fd25966b6ccac1ece1490e06241
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Instead of using std::thread, use the WinRT ThreadPool to manage
threads. This allows for setting the scheduling priority, and provides
a path to enable XAML integration (which requires Qt run on a background
thread).
QThread::terminate() is still unsupported, and only the winmain thread
can be adopted due to the behavior of the thread pool when creating
tasks from the GUI thread. The associated tests are now skipped, and
all other QThread tests pass.
Task-number: QTBUG-31397
Change-Id: Ib512a328412e1dffecdc836bc39de3ccd37afa13
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
The intent is to provide compile time validation of signals and to help
detect signal overloading in the future.
Change-Id: I9d5d46ed4b70c5d0cd407deb5928b1e76d37e007
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
The tasks might not have run yet at the time of the QCOMPARE, so we need
to acquire on the semaphore in order to ensure that this is the case,
just like in the previous testcase.
Change-Id: I1da72bb07c2f53760b3bf912fc26aaf10ed18d48
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
MSVC 2008 is confused by TypeInStruct being a template, resulting in
\tst_qatomicinteger.cpp(189) : error C2027: use of undefined type 'QStaticAssertFailure<Test>'
with
[
Test=false
]
for int (and thus for all unsupported types). This appears to be a real
Heisenbug-nature compiler bug as it can also be fixed by adding
qDebug() << Q_ALIGNOF(TypeInStruct<T>)
before the static assert.
Task-number: QTBUG-37195
Change-Id: Ib2b60f3c1ffeb0b8bdeb1fb0c659655ce4ab10d8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is extremely useful, since the most common action after a failed
compare-and-swap is to loop around, trying again with the current
value as found in memory.
Code currently written as:
do {
Type value = atomic.load();
...
} while (!atomic.testAndSetRelaxed(value, desired));
Becomes:
Type value = atomic.load();
do {
...
} while (!atomic.testAndSetRelaxed(value, desired, value));
In most CPU architectures, the value that was found in memory is known
to the compare-and-swap code, so this is more efficient than the
previous code. In architectures where the value is not known, the new
code is no worse than before.
The implementation sometimes modified an existing function, sometimes
it added a new one, depending on whether more registers were needed in
the assembly (like ARMv6-7), the code became more complex (ARMv5), the
optimizer failed (C++11), or it was just plain equivalent (MIPS).
Change-Id: I7d6d200ea9746ec8978a0c1e1969dbc3580b9285
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
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
Tweak a handful of tests which didn't compile on this platform.
Change-Id: I208d9eb289dfb226746c6d0163c3ea752485033b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
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>
Change-Id: Ib1047731667ba8a7b9db2f62924eb42a6b85b4fd
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@digia.com>
Change-Id: I88d98421978e0f5c55af8647f3f74c265b45bd37
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@digia.com>
- Remove irrelevant test subdirs via .pro files
- Follow WinCE codepaths where applicable
- Replace unsupported Win32 APIs with WinRT equivalents
This does not aim to fix any failures in the tests themselves; it only
makes them compile.
Change-Id: Ia82bc0cc402891f8f6238d4c261ee9152b51be80
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Fixes the obvious race between the test of 'release' in the thread
and the setting of 'release' in the test function.
Change-Id: I92df52d7b18e8154f17229a3dbd4a0e58f4a3b5b
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
The code uses a QSignalSpy to check whether the thread started,
but the signal emission (and subsequent appending to the spy) and
the check for spy.count() before the final thr.wait() are not
synchronized:
The signal emission happens-after the thr.start() and -before the
final thr.wait(). Likewise, the spy.count() happens-after thr.start()
and -before thr.wait(), but neither one happens-before the other.
Thus, there is a data race.
The wait(200) between thr.start() and mutex.unlock() doesn't help,
either, because we check only that it doesn't return true, iow, we
check that it timed out. But it will happily do that if the thread
has not yet started executing, so there's no happens-before relation
to be had via that avenue, either.
I first fixed by moving the spy.count() check to after thr.wait().
In that case:
signal emission happens-before thread finishing
happens-before thr.wait() returning
happens-before spy.count()
so no race.
Arguably, that makes the check rather useless, so I decided to remove
it completely.
Change-Id: I6bb47c4114961ee6e9251cfebeb4b7794ba674a9
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
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>
(dacf9961da)
In order to see 2 active threads, we must check activeThreadCount() before
the runnable finishes.
Change-Id: I1a48b41e0c1fd81a65d915b9bd1e741ff267ed2b
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
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::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>
The optimisation done in cbaf52b099 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>
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>
The macro was made empty in ba3dc5f3b5
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>
Qt 4.8 shows frequent crashes in runMultiple apparently caused
by the QMutex construction in the free functions by different
threads. Use a common QMutex class member instead.
Change-Id: I851d4e2d3637a7b4f404ed843f5360c10caa21f5
Reviewed-by: Mitch Curtis <mitch.curtis@digia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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>
The timeout is in millisecond. So we just need to divide by 1000 to get
the number of seconds
Regression introduced in f587e8f4fd
Reported in the comments of QTBUG-24795
Change-Id: Id16e05e7d04d33605860926f7516d14cdefd6a36
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
To avoid leaking when converting a QFuture<T> to a QFuture<void> we need
to have a separate ref. counter for QFuture<T>. When the last QFuture<T>
goes out of scope, we need to clean out the result data.
Task-number: QTBUG-27224
Change-Id: I965a64a11fffbb191ab979cdd030a9aafd4436c2
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Normalise all signal/slot signatures in tests/*/corelib,
except in tst_QObject, where they might be test data.
Change-Id: Id4e101f285b1676bb583b0afae06d235e599e24b
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
The signal is removed from the API; all references to it are removed
from documentation; the unit test that checks for its emission is
modified to listen for QThread::finished() instead.
The QThreadPrivate::terminated flag is also removed, as it served no
purpose other than to trigger the emission of QThread::terminated()
As discussed at http://lists.qt-project.org/pipermail/development/2012-October/007216.html
the signal is not guaranteed to be emitted after every termination,
rendering it useless.
Change-Id: I7b0c45d7889da0d33875545331606f2208ee56fc
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Instead omit the whole test when Q_OS_WINCE is defined.
Change-Id: Id6f4e65c994115b8bab45f9fbf21dd255d204ea6
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
This class belongs to QThreadPool/QRunnable more than to QtConcurrent, so
move to QtCore, where QThreadPool awaits it.
Change-Id: Ibf20288a986593bf779453427c2dae8db1e1423a
Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
No compatibility header needed. While this wasn't marked as private API,
it wasn't documented, either.
This is a prerequisite for moving QFuture to QtCore.
Change-Id: I8e986e6e2a22fbe5cf08d0600ec39ae9ae993e20
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change copyrights and license headers from Nokia to Digia
Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
