Add parentheses after function names, replace
is different -> differs
Change-Id: I6332db1d1650ed8d8320c5f20cd79d0bf1870e27
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
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>
Introduce helper functions switch_{on,off,from_to} to make
the code more readable, and prepare everything for later
optimizations reducing the sizes of critical sections (by
locking the mutex later, or even never).
This commit, however, is only concerned with shutting up
tsan.
In waitForResult(), simplified the code by removing an
unneeded if guard: the condition is checked in the while
loop immediately following in the then-block, and the
local variable declaration that precedes the loop is not
worth guarding.
Change-Id: I24bfd864ca96f862302536ad8662065e6f366fa8
Reviewed-by: David Faure <david.faure@kdab.com>
Remove most type traits from qtypetraits.h, but keep the custom
implementation of is_signed/is_unsigned. This gets rid of
BSD-3 licensed code from Google in a public header (hugh!).
The custom implementations for is_signed/is_unsigned are kept
because the implementations in gcc's standard headers do not
work as we expect for enums - both is_signed and is_unsigned
always returns false there - see also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027
[ChangeLog][QtCore][General] Qt now relies on type traits from
the C++ standard library.
Change-Id: I3f2188b46949f04ca4482a6ac9afd3482103f0e1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is an improvement for the following reasons:
- Should mutex locking allocate any kind of resource,
unlocking in reverse order will free those resources
in inverse order, which helps typical allocators.
- If the lock pair is contended, by unlocking in the
same order as locking, we were allowing the waiting
thread to wake up to take the first lock just to
find that the second lock is still held by someone
else.
The order of unlocking has no influence on the correct-
ness of the algorithm.
Change-Id: Id16b0342aef325c14a7bd8836d3a75db68ef2588
Reviewed-by: David Faure <david.faure@kdab.com>
Comparing pointers that do not point into the same array using
operator< is UB. You need to use std::less<>.
The QOrderedMutexLocker ctor already used std::less to compare
pointers, but the static relock() function was not fixed.
Amends 5007352164.
Change-Id: I584d382391dd5a2af75020a4e77f3e42ee5d5708
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Section 30.4.1.3 [thread.timedmutex.requirements] has 16 paragraphs and
2 subsections.
Change-Id: I9093948278414644a416fffd1473fec7fdd2716c
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
cf53aa21bf and 3aaa5d6b32
were reverted because of reconstruction in 5.7.
defineTest(qtConfTest_checkCompiler) in configure.pri is smart
enough to cover the case in a9474d1260.
DirectWrite: Fix advances being scaled to 0
Since 131eee5cd, the stretch of a font can be 0, meaning
"whatever the font provides". In combination with ec7fee96,
this would cause advances in the DirectWrite engine to be scaled to
0, causing the QRawFont test to fail.
Conflicts:
configure
mkspecs/features/uikit/device_destinations.sh
mkspecs/features/uikit/xcodebuild.mk
src/corelib/global/qglobal.cpp
src/corelib/global/qnamespace.qdoc
src/plugins/platforms/cocoa/qcocoamenuitem.h
src/plugins/platforms/windows/qwindowsservices.cpp
src/plugins/platformthemes/gtk3/qgtk3dialoghelpers.cpp
src/plugins/platforms/windows/qwindowsfontenginedirectwrite.cpp
src/widgets/kernel/qapplication.cpp
tests/auto/widgets/dialogs/qfiledialog/tst_qfiledialog.cpp
tests/auto/widgets/dialogs/qfiledialog2/tst_qfiledialog2.cpp
Change-Id: I4656d8133da7ee9fcc84ad3f1c7950f924432d1e
Since Qt 5.6.0, some applications such as Kate (built with clang, libc++
and libcxxrt) on FreeBSD occasionally crash with the following error
message on exit:
QMutex::lock(): sem_wait failure: Invalid argument
[or pthread_cond_wait in the 5.6 branch]
Investigation by Gleb Popov, Thiago Macieira and Olivier Goffart has
shown that this is caused by the fact that QDBusConnectionManager is a
Q_GLOBAL_STATIC (so it will be destroyed with all the other
Q_GLOBAL_STATICs in the reverse order of construction). In the
Q_COMPILER_THREADSAFE_STATICS case, freelist() also returns a
function-level static that is constructed on first use, so it may be
destroyed earlier than the QDBusConnectionManager object, making it
impossible to lock a contended mutex.
We now make freelist() return a global static, so that it is always
destroyed after QDBusConnectionManager and other function-static
variables.
Change-Id: I210fa7c18dbdf2345863da49141b9a85cffdef52
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
This fixes a problem that occurs when a task, that is run synchronously,
throws an exception. If that happened, then the exception would not be
re-thrown, because of an early return.
Task-number: QTBUG-54831
Change-Id: Ic70c5b810ec6adce6e62bfd6832ba9f170b13a7f
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Fix the occurrences where the wrong classes are mentioned.
Change-Id: Ia291af77f0f454a39cab93e7376a110c19a07771
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The compiler-generated ones are just fine.
This is BC because the class is not exported and
QFutureInterfaceBase (needlessly) contains virtual
functions (the dtor), so this class will never be
trivially copyable. It's also not movable, until I
figure out how to add move special member functions
to QFutureInterfaceBase.
Also made the QFutureInterface(State) constructor
explicit, because a State is not a faithful
representation of a QFutureInterface.
Change-Id: Ifa44f87b41c4ee3c5167c282512ec4860075671d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This makes the API more consistent with the STL, which helps discovering
the API. Much like QVector has push_back etc.
Change-Id: I75f6b77ab94233c15e17f66605f4bf13aa03e61c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
Conflicts:
qmake/library/qmakebuiltins.cpp
qmake/library/qmakeevaluator.cpp
qmake/library/qmakeevaluator.h
qmake/project.h
QMakeEvaluator:
* evaluateConditional(): one side changed return type, the other
changed a parameter type.
* split_value_list(): one side changed a parameter adjacent to where ...
* expandVariableReferences(): ... the other killed one overload and
changed the survivor
src/corelib/io/qlockfile_unix.cpp
One side changed a #if condition, the other moved NETBSD's part of
what it controlled.
src/corelib/tools/qdatetime.cpp
One side fixed a reachable Q_UNREACHABLE in toMSecsSinceEpoch(), the
other moved it from the private class to the public one, in the midst
of the "short date-time" optimization, which confused diff entirely.
One side changed a QStringLiteral to QLatin1String, the other rewrote
adjoining code.
src/network/kernel/qauthenticator.cpp
Both rewrote a line, equivalently; kept the dev version.
src/platformsupport/fontdatabases/mac/qfontengine_coretext.mm
src/platformsupport/fontdatabases/mac/qfontengine_coretext_p.h
One side changed #if-ery that the other removed.
tools/configure/configureapp.cpp
One side added a check to -target parsing; the other killed -target.
tests/auto/testlib/selftests/expected_cmptest.lightxml
tests/auto/testlib/selftests/expected_cmptest.teamcity
tests/auto/testlib/selftests/expected_cmptest.txt
tests/auto/testlib/selftests/expected_cmptest.xml
tests/auto/testlib/selftests/expected_cmptest.xunitxml
Regenerated using generate_expected_output.py
I note that quite a few other expected_* come out changed, now.
There was no git-conflict in
src/widgets/kernel/qformlayout.cpp
but it didn't compile; one side removed some unused methods; the other
found uses for one of them. Put FixedColumnMatrix<>::removeRow(int)
back for its new user.
Change-Id: I8cc2a71add48c0a848e13cfc47b5a7754e8ca584
Align ourselves to what std::thread does (and what's sensible to do anyhow,
since we even document that "Deleting a running QThread [...] will probably
result in a program crash").
[ChangeLog][QtCore][QThread] Destroying a QThread which is still running will
now result in immediate and abnormal program termination.
Change-Id: Ib481287915be01a1381df14abf6e0fb68c36b5b5
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When one tries to lock without a timeout, there is no need to allocate
a QReadWriteLockPrivate as we will not wait on it.
Change-Id: I37c96a7fbc0c66fbdffe372f6089708cb2466fe3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The rule was:
- if the header included qglobal.h, turn that into qglobal_p.h
- otherwise, insert the #include after the "We mean it" warning
qglobal_p.h currently only includes qglobal.h.
Change-Id: Ib056b47dde3341ef9a52ffff13ef677e471674b7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
And blacklisted a few tests in tst_QUdpSocket.
Conflicts:
src/android/jar/src/org/qtproject/qt5/android/QtNative.java
src/corelib/global/qglobal.cpp
src/corelib/global/qsystemdetection.h
src/corelib/io/qfileselector.cpp
src/plugins/platforms/eglfs/deviceintegration/eglfs_kms_egldevice/qeglfskmsegldeviceintegration.cpp
tests/auto/network/socket/qudpsocket/BLACKLIST
Task-number: QTBUG-54205
Change-Id: I11dd1c90186eb1b847d45be87a26041f61d89ef6
Push conversions from pthread_t to Qt::HANDLE and back into functions.
The casts that were being used didn't work for the unusual 64-bit
pointer/32-bit int combination that QNX is using for 7.0. HANDLE ends
up as a 64-bit pointer and pthread_t ends up as a 32-bit integer. g++
considers the precision loss when converting from the 64-bit pointer
to the 32-bit integer an error. Better to have the casts hidden in
functions so it's easier to adjust them for unusual combinations such
as this.
Change-Id: Ia156b26224a0f7edc1c31e3d1ee8b21191381698
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This commit also reverts fecaa6aae8.
The Microsoft documentation says _beginthreadex and _endthreadex are
used to initialize the C/C++ runtime and are necessary when linking to
libcmt(d).lib (that is, when using the -MT or -MTd options). For regular
builds linking against the .dll runtime, there should be no impact.
Inspection of the CRT source code which gets installed with Visual
Studio or Windows SDK proves that.
It's preferable to use CreateThread directly as _endthreadex will try to
call FreeLibraryAndExitThread, which can cause a deadlock if we try to
wait for the thread to exit from a global destructor.
For -MT builds, since there can be no DLLs, it's not a problem to
continue to use _beginthreadex and follow Microsoft's recommendation.
Task-number: QTBUG-53031
Change-Id: Id5480807d25e49e78b79ffff144af62c3c59dfe0
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
It was added in 2.6.22. If we pass it to 2.6.21, we'll get -ENOSYS,
which is bad for QMutex. This fix simply defines it to 0 if the header
doesn't define it.
But as a consequence: if Qt is built with newer kernel headers, it won't
run on older versions. It's not likely that someone is still using Qt
5.7 on a 2.6.21 kernel (v2.6.21.7 was released on 2007-08-04).
Change-Id: Icb178bb113bb437c9b67fffd1451dd7bb964f0c8
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
This reverts commit 4579d966af.
This causes a miscompilation with ICC 16 on Windows (MSVC 2015 ABI): the
vector created by new[] with () in:
mutexes(new QAtomicPointer<QMutex>[size]()), // (): zero-initialize
does not actually zero-initialize (see disassembly in the bug
report). This is definitely a compiler bug.
Since we plan on removing QMutexPool in Qt 5.8 anyway, let's just revert
the patch.
Task-number: QTBUG-53360
Change-Id: I06bae9392f534e45b3f1ffff144e823b747e7962
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
The flag was introduced in kernel 2.6.22, but we're already depending on
features added on 2.6.23 in qcore_unix_p.h (pipe2, dup3, O_CLOEXEC) and
2.6.27 in qnet_unix_p.h (accept4 and SOCK_CLOEXEC).
Change-Id: Id5480807d25e49e78b79ffff144a093c9e30cd96
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is source- and binary-compatible, including the marking of the
existing function as noexcept.
[ChangeLog][QtCore][QMutex] Made the isRecursive() method be a const
function so that it can be called in const QMutex objects too.
Change-Id: Ifea6e497f11a461db432ffff1448bead97c08f92
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
We were using direct loading and operator=, which for everything except
std::atomic was very relaxed. But std::atomic<T *> defines the direct
access to actually be the least relaxed possible, under the idea that if
you didn't know any better to use a member function, you probably need
the most protection.
So use Ops::load and Ops::store.
Change-Id: Id5480807d25e49e78b79ffff144a06a2e6398576
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
It always returns the same information for each thread it is called
in. But since it's different per thread, we don't think it's
const. pthread_self() on Linux is marked const, though we think it
really ought to be pure. On other OSes, the annotation isn't present,
but the we can assume function is so.
Change-Id: Ifea6e497f11a461db432ffff1448c2b37d94d5f3
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
It was being stored once in QThreadPrivate and once in QThreadData, with
the latter being hidden as a Qt::HANDLE. Besides saving a little bit of
memory, this also solves a small data race condition that arises from
trying to connect a signal to an object moved to that thread and then
emit that signal shortly after the thread starts. Before this patch,
QThreadData::threadId was initialized only by QThreadPrivate::start(),
which meant that we were racing that initialization with this check in
QMetaObject::activate:
const bool receiverInSameThread = currentThreadId == receiver->d_func()->threadData->threadId;
Task-number: QTBUG-52337
Change-Id: Ifea6e497f11a461db432ffff1449ae01f1099aae
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Ulf Hermann
Marc Mutz
Liang Qi
Oliver Wolff
Kai Koehne
Thiago Macieira
Raphael Kubo da Costa
Christian Strømme
Oswald Buddenhagen
Jake Petroules
Friedemann Kleint
David Faure
Giuseppe D'Angelo
Edward Welbourne
Olivier Goffart
James McDonnell