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>
