Remaining uses of Q_NULLPTR are in:
src/corelib/global/qcompilerdetection.h
(definition and documentation of Q_NULLPTR)
tests/manual/qcursor/qcursorhighdpi/main.cpp
(a test executable compilable both under Qt4 and Qt5)
Change-Id: If6b074d91486e9b784138f4514f5c6d072acda9a
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Remaining uses of Q_DECL_OVERRIDE are in:
src/corelib/global/qcompilerdetection.h
src/corelib/global/qglobal.cpp
doc/global/qt-cpp-defines.qdocconf
(definition and documentation of Q_DECL_OVERRIDE)
tests/manual/qcursor/qcursorhighdpi/main.cpp
(a test executable compilable both under Qt4 and Qt5)
Change-Id: Ib9b05d829add69e98a86238274b6a1fcb19b49ba
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Since MSVC doesn't have <chrono> (according to QT_HAS_INCLUDE), the QSKIP
in the test was printed for every line in the table. Instead, add the
skip in the _data() function.
Change-Id: I6e9274c1e7444ad48c81fffd14dbcee5e5a322aa
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Allows setting the stack size for the thread pool
worker threads. Implemented using QThread::stackSize.
Task-number: QTBUG-2568
Change-Id: Ic7f3981289290685195bbaee977a23e0c3c49bf0
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Qemu uses some memory for each generated thread. This test creates
> 80000 threads and consumes about 10Gb of memory which is too
heavy for a VM.
Task-number: QTBUG-59966
Change-Id: I1bb8a0d7955778f5201948b41befcb9f1f391514
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
tryAcquireWithTimeout(0.2s) was already blacklisted and
now the same failed with "(2s)".
Task-number: QTBUG-58745
Change-Id: I82363238c08056d2969a7616e3a6e5af080d537d
Reviewed-by: Liang Qi <liang.qi@qt.io>
In the spirit of std::thread, which takes a function to call and its
parameters, and runs it in a new thread. Since the user might want to
connect to signals, move QObjects into the new thread, etc., the new
thread is not immediately started.
Although technically all of this _should_ be implementable in pure
C++11, there is nothing in the Standard to help us not reinvent all the
plumbing: packing the decay'd parameters, storing them, invoking the
function over the parameters (honoring INVOKE/std::invoke semantics).
std::function does not do the job, as it's copiable and therefore does
not support move-only functors; std::bind does not have INVOKE
semantics.
I certainly do not want to reimplement all the required facilities
inside of Qt. Therefore, the full blown implementation requires C++17
(std::invoke).
In order to make this useful also in pre-C++17, there are two additional
implementations (C++11 and C++14) that support just a callable, without
any arguments passed to it. The C++11 implementation makes use of a
class to store and call the callable (even move-only ones); basically,
it's what a closure type for a C++14 lambda would look like.
An alternative implementation could've used some of the existing
facilities inside QObject::connect implementation that store a functor
(for the connect() overload connecting to free functions), namely:
the QtPrivate::QFunctorSlotObject class. However:
* QFunctorSlotObject does not support move-only callables (see
QTBUG-60339);
* QFunctorSlotObject itself is not a callable (apparently by design),
and requires to be wrapped in a lambda that calls call() on it;
* the moment QTBUG-60339 is solved, we'd need the same handwritten
closure to keep QFunctorSlotObject working with move-only callabes.
So: just use the handwritten one.
The C++14 implementation is a simplified version of the C++11 one,
actually using a generalized lambda capture (corresponding to the
handwritten C++11 closure type).
All three implementations use std::async (with a deferred launch policy,
a nice use case for it!) under the hood. It's certainly an overkill for
our use case, as we don't need the std::future, but at least std::async
does all the plumbing for us.
[ChangeLog][QtCore][QThread] Added the QThread::create function.
Change-Id: I339d0be6f689df7d56766839baebda0aa2f7e94c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If the respective modules aren't available we cannot build the tests
and examples. We drop the qtConfig(opengl) requirement for the opengl
examples as
a, we would need to make the QtGui configuration available for that to
work, and
b, we should not add too much detail to the tests and examples build
configurations. Checking each test and example for every feature it
uses would be too much.
Task-number: QTBUG-57255
Change-Id: Ifb043c81ec9e5c487765297bd65704812cd281fc
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
It has started failing recently on the CI, too.
Task-number: QTBUG-58745
Change-Id: I4c8834917e6455d00c300549ed448b06da75d5bc
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Let's take the beginning of the description: WaitForSingleObjectEx can
be up to 16 milliseconds early. This is proven by the fact that there
are tests doing:
wait(waitTime);
QVERIFY(timer.elapsed() >= waitTime - systemTimersResolution);
and failing.
Task-number: QTBUG-59337
Change-Id: Iae839f6a131a4f0784bffffd14a9a79523d69d94
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
ResultStore never actually exists, only ResutStoreBase does. So casting to
ResultStore<T> and calling its member functions is UB. Put the type dependent
function as template member functions within ResultStoreBase and so we don't
need QtPrivate::ResultStore anymore.
Same goes for the iterator.
Change-Id: I739b9d234ba2238977863df77fde3a4471a9abd2
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Replace all QT_NO_PROCESS with QT_CONFIG(process), define it in
qconfig-bootstrapped.h, add QT_REQUIRE_CONFIG(process) to the qprocess
headers, exclude the sources from compilation when switched off, guard
header inclusions in places where compilation without QProcess seems
supported, drop some unused includes, and fix some tests that were
apparently designed to work with QT_NO_PROCESS but failed to.
Change-Id: Ieceea2504dea6fdf43b81c7c6b65c547b01b9714
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The cancel() function added in 5b11e43e for Qt 5.5 suffers from a
number of problems:
First, if runnable->autoDelete() is true, then the function suffers
from the ABA problem (see documentation written for trytake()).
Second, if runnable->autoDelete() is false, due to cancel() throwing
away crucial information instead of returning it, the caller cannot
know whether the runnable was canceled (and thus has to be deleted),
wasn't found or is currently executing (and thus mustn't be deleted),
or has finished executing (and can be used to extract the result).
Deprecate this dangerous API and replace it with the much more useful
Private::stealRunnable(), promoted to public API and renamed to
tryTake() for consistency with the rest of Qt.
Described the various caveats in the function's documentation.
[ChangeLog][QtCore][QThreadPool] The cancel() function suffers from
several subtle issues and has been replaced with a new tryTake()
function.
Change-Id: I93125935614087efa24b3e3969dd6718aeabaa4f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
We keep the runnables from finishing by having them block
on a QSemaphore::acquire() call inside run().
If we fail a test that precedes the call to sem.release()
further into the test, the early return will cause the
thread pool to be destroyed, which will then attempt to
wait for the runnables to finished, which, in turn wait
for the semaphore to be released.
-> dead lock
Fix by introducing a RAII object to release the semaphore
with a sufficiently large number to unblock all runnables.
That number will in some situations be too large, but that
does not matter.
Change-Id: I1ec7e29b37bc36309e93e6e30708cc7db3c9579c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In order to get reproducible runs of the test, we need to
wait in the main thread until all runnables have started
executing. Otherwise, what the cancel() loop below actually
does will vary from run to run.
Change-Id: Ib912b0943e7bbd55c9480ae6fd4011ba20ac457e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Instead of allocating a statically-sized array on the heap,
use an automatic C array instead.
Replace some magic numbers with named constants.
Change-Id: I17d29a76a67c4a413453ac26a5dee8cd54a8a37d
Reviewed-by: David Faure <david.faure@kdab.com>
Manipulating a simple int from multiple threads is a data race,
thus undefined behavior.
Fix by using QAtomicInt and atomic operations instead.
Change-Id: I5418bc260da57fe353a71b8e5c7c1c97adbe7597
Reviewed-by: David Faure <david.faure@kdab.com>
When one of the QCOMPAREs in Consumer::run() fails, the consumer
returns early, leaving the producer deadlocked in a QSemaphore's
acquire() call. Change these to tryAcquire() with a large timeout,
so the producer, too, eventually leaves run().
Change-Id: I7421d43305decd4754e09c8e092363594d1be06b
Reviewed-by: David Faure <david.faure@kdab.com>
This test was determined to be flaky on the CI.
Task-number: QTBUG-58741
Change-Id: I43196d3a27f726fb96b427f5071e726b571a0404
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
This is a simple RAII class that makes semaphore releasing
reliable in the face of exceptions and early returns.
This code originates from KDTools' KDSemaphoreReleaser[1], but
has been extensively reworked to support C++11 move semantics.
[1] https://docs.kdab.com/kdtools/2.3.0/class_k_d_semaphore_releaser.html
[ChangeLog][QtCore][QSemaphore] Added a new RAII class, QSemaphoreReleaser,
to reliably perform release() calls.
Change-Id: I6aff64d37cc0882b17c4419817bde60b542f34d9
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This test was determined to be flaky on the CI, depite attempts
to stabilize it (b750a3786f).
Task-number: QTBUG-58745
Change-Id: I933199cd537002699906147d172bb797f1dc90c1
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The future tests don't need QtConcurrent as QFuture and friends are in
QtCore. The printdevice test doesn't use QtNetwork and the lancelot as
well as the testlib tests don't use QtXml.
Change-Id: I150ac99b36682aa23ad22ba943266eb0f0952838
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This new function does the same as newRow(), except that it has a less confusing
name (in line with _add_Column()), and accepts printf-style arguments to avoid
the need to newRow(qPrintable(QString::asprintf())), a common pattern in client
code. It uses qvsnprintf() under the hoods, avoiding the need for the QString
const char* round-trip.
Port all in-tree users of newRow(qPrintable(QString::asnprintf())) to the new
function.
Change-Id: Icd5de9b7ea4f6759d98080ec30f5aecadb8bec39
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The test was so slow it was blacklisted on all platforms for timing out.
This patch lowers the timeout to a 5th and tries removing the blacklist.
Change-Id: Ib28b21de572517c548a14300f26815598efe91e2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
By templating on the <chrono> types and unconditionally using
duration_cast to coerce the duration into a milliseconds, we
allowed code such as
mutex.try_lock_for(10us)
to compile, which is misleading, since it's actually a zero-
timeout try_lock().
Feedback from the std-discussions mailing list is that the
wait_for functions should wait for _at least_ the duration
given, because that is the natural direction of variance
(tasks becoming ready to run might not get a CPU immediately,
causing delays), while an interface that documents to wait
_no more_ than the given duration is promising something it
cannot fulfill.
Fix by converting the given duration to the smallest number
of milliseconds not less than the original duration. If that
is not representable in an int, use INT_MAX, emulating the
effect of a spurious wakeup, which are allowed to happen if
the function returns false in that case.
In the above example, the try_lock_for call is now equivalent
to
mutex.tryLock(1);
The tryLock() docs state that the actual waiting time does
not exceed the given milliseconds, but fixing that is a
separate issue.
Change-Id: Id4cbbea0ecc6fd2f94bb5aef28a1658be3728e52
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This test fails on Windows occasionally with values just short of 800, the lowest
observed being 791. It is probably rounding somehow to 10ms segments, so allow
it to be up to 10 ms too fast.
Change-Id: Ie28e9f61588b68a9060a006f78eedc3a26d05155
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Consistent with other Unix platforms, and internally consistent between tests,
as a lot of tests were already applying CONFIG -= app_bundle manually.
Change-Id: Icd2b7e1c08015b26137af60ff82fddbc753f0ff4
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
The adoptedThreads test never spawned any thread causing a test error
later on. Hence add a winrt version using __beginthreadex which exists
for that platform.
Change-Id: I04f980218713df20cb41d804d732e0c99b958489
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Now QBasicMutex is Lockable and QMutex is TimedLockable, which means they can
be used in std::lock_guard, std::unique_lock, std::lock, etc.
[ChangeLog][QtCore][QMutex] QMutex now fully models the TimedLockable
concept by providing the try_lock, try_lock_for and try_lock_until
functions, therefore making it usable in Standard Library lock
management classes and functions.
Change-Id: I7c691481a5781a696701e1ab78186b5cefbd6a87
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
This requires fixing the test on Windows: QMutex internally uses
WaitForSingleObjectEx which can wake up early, according to the system
timer resolution:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms687069(v=vs.85).aspx#waitfunctionsandtime-outintervals
QTime must be so slow that it hides the early wakes, but QElapsedTimer is
accurate enough to make the test fail unless we add back some tolerance to
compensate for the early wakeups.
Change-Id: I20b38af9c87a0b0e38a19b9bff1c3c24975c78f5
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Drop addSub() test. It executes exactly the union of fetchAndAdd()
and fetchAndSub(), which have already had their UBs fixed.
No need to do fixes in duplicated code.
Change-Id: Ib72caab0310fce3ff9a40c261d8a38518f91ecaf
Reviewed-by: David Faure <david.faure@kdab.com>
This change partially reverts 1bfc7f68 about QT_HAS_BUILTIN define
and undef in src/corelib/tools/qsimd_p.h.
This change is also squashed with "Fall back to c++11 standard
compiler flag for host builds" which is done by Peter Seiderer.
Conflicts:
mkspecs/features/default_post.prf
src/3rdparty/sqlite/0001-Fixing-the-SQLite3-build-for-WEC2013-again.patch
src/3rdparty/sqlite/sqlite3.c
src/corelib/tools/qsimd_p.h
src/gui/kernel/qevent.cpp
src/gui/kernel/qwindowsysteminterface.cpp
src/gui/kernel/qwindowsysteminterface_p.h
src/plugins/bearer/blackberry/blackberry.pro
src/plugins/platforms/cocoa/qcocoasystemsettings.mm
src/plugins/platformthemes/gtk2/gtk2.pro
src/plugins/styles/bb10style/bb10style.pro
src/sql/drivers/sqlite2/qsql_sqlite2.cpp
tools/configure/configureapp.cpp
Task-number: QTBUG-51644
Done-with: Peter Seiderer <ps.report@gmx.net>
Change-Id: I6100d6ace31b2e8d41a95f0b5d5ebf8f1fd88b44
Signed integer overflows and underflows are undefined
behavior. A test that invokes UB tests nothing, because
the standard permits any outcome.
Fix by guarding the respective operations so
they are not executed if they would overflow
or underflow.
Change-Id: I40354ee88f40e4b47b70eac7790dc3a79ac70a57
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
I wrote a script to help find the files, but I reviewed the
contributions manually to be sure I wasn't claiming copyright for search
& replace, adding Q_DECL_NOTHROW or adding "We mean it" headers.
Change-Id: I7a9e11d7b64a4cc78e24ffff142b506368fc8842
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Not that we require it, but since The Qt Company did it for all files
they have copyright, even if they haven't touched the file in years
(especially not in 2016), I'm doing the same.
Change-Id: I7a9e11d7b64a4cc78e24ffff142b4c9d53039846
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
From Qt 5.7 -> tools & applications are lisenced under GPL v3 with some
exceptions, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new GPL-EXCEPT header instead of LGPL21 one
(in those files which will be under GPL 3 with exceptions)
Change-Id: I42a473ddc97101492a60b9287d90979d9eb35ae1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
[ChangeLog][Important Behavior Changes] Starting with Qt 5.7, Qt
requires a C++11 compiler with support for C++11 atomics. This affects
user code too: Qt headers no longer compile with a C++98 compiler. The
minimum compiler versions for this release are:
* Clang 3.4 (found in XCode 5.1)
* GCC 4.7
* Microsoft Visual Studio 2012
Change-Id: Ib056b47dde3341ef9a52ffff13ef1f496ea9363f
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
TEST_HELPER_INSTALLS cannot be used on platforms with no
QProcess support.
Change-Id: I2a6a283d94ca4487fc628449c53fc37140dd291d
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Replace hardcoded interval by QTRY_COMPARE() ensuring that all tasks have
finished, since otherwise QThreadPool::tryStart() fails in the next run.
Remove blacklisting for MSVC2012 since it is not compiler-specific.
Task-number: QTBUG-49654
Change-Id: If49b6eb9ef4da4ba2911839166c397d84c175e00
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Introduce constants and make the interval for the 2nd thread a bit
longer.
Task-number: QTBUG-49653
Change-Id: I92ac0494ec6c9af5bde858007d08e26210215434
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Introduce a base class for the threads that ensures termination in the
destructor to ensure all QThreads instantiated on the stack are terminated.
This should reduce crashes since the test thread classes have pointers
to stack variables of the test slots.
Set object names on the threads for better diagnostics.
Decouple wakeOne()/wakeAll() that impact each other via the static count
variables of the thread class by introducing a base class WakeThreadBase
keeping a pointer to an QAtomicInt count variable on the stack instead
(similar to the existing pointers to the mutexes, etc).
Task-number: QTBUG-49653
Change-Id: I73537386bf36019efa81e8e24ba9af92506f7794
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
If the future is finished when a watcher starts watching it, it is
perfectly reasonable for the watcher to get the finished message
promptly. If you pause the watcher before any message loops get to
run, the message presently won't get through until the watcher is
resumed, but there is no reason to guarantee that; indeed, one could
consider it somewhat perverse behavior.
So move the reportFinished() calls to after the pause()s.
Also eliminate a used-once local variable and use QTRY_VERIFY() in one
place where qWait() was used before.
Change-Id: I4bc6091fd7437a4d341be511b7a140f3d72d850e
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Attaching spies afterwards was provoking a warning during tests:
QFutureWatcher::connect: connecting after calling setFuture() is likely to produce race
Change-Id: I6ee8c3613cecebd1c69b0337139d8a19a33f4a11
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
It's accessed by QFutureWatcherBase::isFinished(), potentially before
anything has set it. It gets to be initially true until setFuture()
has given it us unfinished future and set it false.
Add a regression test for matching state in future and watcher.
Task-number: QTBUG-12358
Change-Id: Iae7bdaa434ab80f518afe4d7d55df99c391991a4
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
This test when running on Windows has a race condition since in qthread_win.cpp the
finished signal is emitted before everything is cleaned up.
Change-Id: I3c03d9a245e297e8f79b2be2c34398bf7bac9bae
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
The keyword no longer has a meaning for the new CI.
Change-Id: Ibcea4c7a82fb7f982cf4569fdff19f82066543d1
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
- Replace Q[TRY]_VERIFY(pointer == 0) by Q[TRY]_VERIFY(!pointer).
- Replace Q[TRY]_VERIFY(smartPointer == 0) by
Q[TRY]_VERIFY(smartPointer.isNull()).
- Replace Q[TRY]_VERIFY(a == b) by Q[TRY]_COMPARE(a, b) and
add casts where necessary. The values will then be logged
should a test fail.
Tests from corelib/tools were omitted in this change.
Change-Id: I4c8786d33fcf429d11b2b624c7cd89c28cadb518
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The function declaration has to be in the same ifdefs as the
implementation.
Change-Id: I78c5795baef4adba7439f66252819963db164759
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Preparing the replacement of Q[TRY]_VERIFY(a == b) by
Q[TRY]_COMPARE(a, b) for non-boolean types.
Change-Id: Iab6ec2f0a89a3adc79e18304573994965013dab5
Reviewed-by: Mitch Curtis <mitch.curtis@theqtcompany.com>
The overload was added for NokiaX86 and RVCT and is bound for
removal.
Task-number: QTBUG-47260
Change-Id: Ic67cee8769847956e16cd0470ebcd663a9e98a40
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since of Windows (Phone) 8.1 most of the desktop's thread functionality
is also available, so we might be able to share the code and get rid of
the extra implementation for WinRT.
Task-number: QTBUG-43837
Change-Id: I0ce907cd94899834527f88c70e1e395bafdb14b3
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
All variants of the tests are timing out randomly on all platforms :(
Change-Id: I9244602a8d06fd07d3cc99b2fb8fdf6e07e92cf2
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
They didn't show up in the "old" CI runs because they usually pass the second
time they are executed - which the testrunner does. The new CI doesn't do that
anymore, instead we now mark those tests explicitly and will track their record
of passing and failing in the new metrics database.
Change-Id: Id34dd6f792f38995b07b6fec88f833df64de2f8b
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Without QProcess support we do not run test which initTestCase is
trying to find.
Change-Id: Icecaad90f61a019489e372517a6d62372155bd46
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Properly QSKIP tests that use disabled QProcess and symlink
features instead of excluding them silently by #ifdef.
Other reason is that moc doesn't respect QT_NO_* defines
in class definition which causes build issues on some
platforms.
Change-Id: I041020f7452f7d36c7ec8a5866a4ba5eb23d1f94
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Jason McDonald <macadder1@gmail.com>
And add tests for the GCC intrinsics and for std::atomic.
Task-number: QTBUG-43794
Change-Id: Ic5d393bfd36e48a193fcffff13b9b2dbaee80469
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
[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>