This function used to reside in QEventLoop in Qt 3 and was deprecated in
Qt 4. However this is useful for those who want to know how many event
loops are running within the thread so we just make it possible to get at
the already available variable.
Change-Id: Ia6a7d94ff443a1d1577633363694bc2fa8eca7e4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jørgen Lind <jorgen.lind@theqtcompany.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>
wait() was always returning immediately, regardless of the timeout
value, due to a timespec comparison from different clock types.
On Android 5.0, qt_gettime() uses the monotonic clock but the wait
condition was using the real time clock.
__pthread_cond_timedwait_relative() is not exported anymore in
Android 5.0, we therefore fall back to pthread_cond_timedwait().
Since the monotonic clock is now available, qt_gettime returns
a time based on it. The wait condition consequently needs
to use the monotonic clock.
Change-Id: Ie7cf909b81107edd7207c3c039b3ec1f5422303f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>
This is a no-op change. It doesn't improve or worsen the code at all.
Change-Id: Ifd5273842370ca9bce0ed74f2f2d54d453797948
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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>
This is useless. The C++ language does require callbacks passed to C
functions to also be extern "C". That's what this macro was doing.
But #ifdef'ing for the macro only made the code uglier. Just let the
extern "C" be there for all compilers.
PS: C++ classes can't be extern "C"...
Change-Id: Ic5d393bfd36e48a193fcffff13b9c9b3923443dd
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
This is primarily to get a cleaner build of src/tools
under -Wnoexcept.
Change-Id: I0dea21e70aad56b25675fc59fac0327b55ee83e3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The "int" was a left over when this was documentation for QAtomicInt.
Change-Id: If7b7688982d27cbbd42f080eff7d08344b587f44
Reviewed-by: Richard J. Moore <rich@kde.org>
[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>
The BSD4 code (including OS X) calls sysctl and if that fails, it sets
cores to -1. Similarly, the generic Unix code calls sysconf() and
assigns the returned value to cores, but sysconf can return -1 on
failure.
Change-Id: I9e521d366e9c42f36c2ba20a37e7a74539ddb8f4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Change-Id: I91ff06644e8047c2ca483f9768b46c1372eb6171
Reviewed-by: Martin Smith <martin.smith@digia.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Done automatically with clang-modernize on linux
(But does not add Q_DECL_OVERRIDE to the function that are marked
as inline because it a compilation error with MSVC2010)
Change-Id: I2196ee26e3e6fe20816834ecea5ea389eeab3171
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We map the Apple Clang versions to upstream, so that we have one
define to compare against.
Fixes build break on iOS due to qbasicatomic.h not defining
QT_BASIC_ATOMIC_HAS_CONSTRUCTORS on Apple Clang versions, which
is needed after 1e9db9f5e1
Change-Id: I17493c0187c20abc5d22e71944d62bfd16afbad2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qatomic_sparc.h was removed previously as part of general cleanup of
old atomic code for Qt 5.3. Unfortunately SPARC include reference was
not removed resulting in build failure on that platform.
Task-number: QTBUG-41384
Change-Id: Ic6e31b32324b0e5dd3700a6a21515a8eea5668bd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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>
Saves us from an extra load in the loop when the result is already
there.
Change-Id: Ib65b5b13f27975b8fc88be9b888c19505bf5e07c
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Conflicts:
mkspecs/qnx-x86-qcc/qplatformdefs.h
src/corelib/global/qglobal.h
src/network/socket/qnativesocketengine_winrt.cpp
src/plugins/platforms/android/androidjniaccessibility.cpp
src/plugins/platforms/windows/qwindowswindow.cpp
Manually adjusted:
mkspecs/qnx-armle-v7-qcc/qplatformdefs.h
to include 9ce697f2d5
Thanks goes to Sergio for the qnx mkspecs adjustments.
Change-Id: I53b1fd6bc5bc884e5ee2c2b84975f58171a1cb8e
Don't create a dispatcher for all adopted threads, only the main thread.
This was causing the GUI thread to skip platform dispatcher creation.
Change-Id: Id0de976f9def48e8d58efd20815b6fd18faebefa
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
qdoc only see a fake QMutex class (the same as the one built in bootstrap)
But that fake QMutex had static member while the normal QMutex class
has non static member.
QMutexLocker::mutex is also a const function in the real QMutexLocker
Task-number: QTBUG-38522
Change-Id: I220434ffc6a9e990029f770e2536ecb55b4e2182
Reviewed-by: Martin Smith <martin.smith@digia.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@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>
There is no guarantee that the handle from std::thread will be valid
when a wait is made. Instead, simply use an elapsed timer and check
if the thread is finished. This prevents an exception from being thrown
when a bad handle is encountered.
Task-number: QTBUG-31397
Change-Id: Ie2a7e6cbfbb27bf1baff779322670d85e92e10dd
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
This allows us to get the current value of the QMutex / QBasicMutex
after the testAndSet operation failed. It saves an extra load from
memory.
Change-Id: I4922a8b3df15e342b177b13f56cf4f1184314520
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
sleep_for appears to be unreliable (resulting in infinite waits) when
used in a thread which is also using native waiting methods. This is
also a step in the direction of eliminating std::thread's usage in WinRT.
Change-Id: I58bc4bf9ada25de247849333ef925964676b7239
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Instead of looping unnecessarily on top of testAndSet.
Task-number: QTBUG-37031
Change-Id: I8120f8405eb76dccc9066749cee0a92b0f2da20e
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Sergio Ahumada <sahumada@blackberry.com>
[ChangeLog][QtCore][Atomic support]Added more operations to the atomic
classes, including operator T(), operator=(T), operator++,
operator--. For the QAtomicInteger, bit-manipulation operations are
also provided, both in operator and in fetchAndXxxYyyyyy modes.
Change-Id: I39c07be74e15e0a48f9e931f4342b182004dee1a
Reviewed-by: David Faure <david.faure@kdab.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>
Don't delete the thread object without detaching it, use detach()
instead of CloseHandle(), and avoid a double-delete.
Change-Id: Ia169a96fb32805e06abe099c3c35e97ce485f088
Reviewed-by: Oliver Wolff <oliver.wolff@digia.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>
No need to redefine everywhere, since they're required to be supported.
Change-Id: I2bdbbd0b0c44871e3bd0edcf0289fc58dd50ff31
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
This is already implemented in qatomic_x86.h, qatomic_ia64.h,
qatomic_mips.h, qatomic_armv6.h, and qatomic_cxx11.h. For
qatomic_msvc.h, we've just fixed it.
For qatomic_gcc.h, we know that the compiler supports it, so just add
it. According to the GCC manual, it might print a warning on some
platforms, so we only enable that on 64-bit builds.
For qatomic_unix.h, the support was missing (along with support for
unsigned 32-bit), so this commits adds it.
For qatomic_armv5.h, the platform does not always support 64-bit
atomics, but ARMv5 cannot compile in 64-bit mode anyway.
Change-Id: Ia8b3b5c641f11e5df05937fe7442be0a223174ef
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
QAtomicInteger<T> is to QBasicAtomicInteger<T> what QAtomicInt was to
QBasicAtomicInt: just a little more syntactic sugar. The Basic classes
do not always have a constructor, since they depend on compiler
support. The constructor is always present in the non-Basic class, at
the expense of making it non-POD for C++98 code.
This commit also repurposes most of QAtomicInt's documentation for
QAtomicInteger. It adds only the Q_ATOMIC_INTnn_IS_SUPPORTED macro
that explains whether the given type is supported on this platform.
Change-Id: I58886d6fa49fea4de24015c40dae29c9fa534e00
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Kurt Pattyn <pattyn.kurt@gmail.com>
When building with debug, all SLOT or SIGNAL macros will
expand to a function call, and then function will call
QThreadData::current(), which will set
QCoreApplication::theMainThread if it has not already been
done. Since Qt Widgets has these macros in the static
initialization of the library, we would register the
Android main thread as the main thread of Qt, which would
mean that the actual application object was created on
a different thread than the main thread. This caused warnings
to appear, and also triggered a race condition which
caused widget applications to sometimes show a black screen
instead of content on startup when run with the OpenGL plugin.
Task-number: QTBUG-35048
Change-Id: Ie8979f5e7cd5662f8d7dd276de9f94f27cc120b5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
the diff -w for this commit is empty.
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: I77bb84e71c63ce75e0709e5b94bee18e3ce6ab9e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- Move private classes in the .cpp file (they aren't needed outside)
- Conform to Qt style, such as includes and braces
- Use ComPtr where appropriate
- Use foreach where appropriate
- Remove non-functional wake/interrupt leftovers
- Remove redundant timer list
- Make the timer callback a static method, so it won't crash if it
gets called on shutdown
Task-number: QTBUG-35945
Change-Id: I5426fba2735e908a04ea60287f9936f5abde6644
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
The new atomic code was introduced in Qt 5.0. The platforms that did not
get ported were announced as deprecated in Qt 5.2. The code is now
removed in Qt 5.3.
The status for the platform/compiler/OS combinations affected is:
* Linux with GCC or Clang: still compiles on all platforms
(via qatomic_cxx11.h or qatomic_gcc.h)
* INTEGRITY with Green Hills compiler: no longer compiles
* Solaris on UltraSPARC, with Sun Studio: no longer compiles
* AIX on POWER5 or 6, with IBM Visual Age: no longer compiles
(probably did not compile Qt 5.0 either)
* VxWorks in kernel mode: no longer compiles
[ChangeLog][General] Support for the following platforms has been
removed, due to lack of interest in updating support: INTEGRITY,
VxWorks, Solaris on UltraSPARC (with the Sun Studio compiler suite), AIX
on POWER processors (with IBM Visual Age compiler suite).
Change-Id: I8a961385fd95011c016b2b1eec52034794dae3e1
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Before, we'd get just an error message that the size of the array was
negative. Now, for C++11 compilers, we get a better error message:
qbasicatomic.h:117:5: error: static assertion failed: Template parameter is not a supported integer on this platform
qbasicatomic.h:119:24: error: invalid use of incomplete type ‘struct QAtomicOps<long long unsigned int>’
Change-Id: I6b0792254c0dc6103a4a7608f2942d59cda07c00
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
The T was missing in QT_BASIC_ATOMIC_HAS_CONSTRUCTORS. This makes
QAtomicInt's constructor become constexpr.
Change-Id: Ibe58ff36517c5d05ce8af9c0f28169fa63521632
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.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
The public documentation for load() and store() says it's atomic,
and it is:
* using _q_value.store(newValue, std::memory_order_relaxed) in the C++11
implementation
* using a simple assignment otherwise, which is atomic (and relaxed, no
memory barriers) on all the existing C++ ABIs.
Change-Id: I40faa47120163225bd11c3a32514ac97ef8bbbd4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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>
Added/Changed:
- Move content from the Thread Basics overview to the QThread class ref
- Rephrase bits for clarity
- Use more links
Removed:
- (threads-basics.qdoc) Warning against moveToThread(this): This usage
came about when people tried to add slots to a QThread subclass. This
patch adds a warning against the root cause.
- (threads-basics.qdoc) Note on sleep() et al.: They were made public in
Qt 5.0.
- (threads-basics.qdoc) The strategy for managing member variables:
Sounds error-prone. Pushing results through signals is safer.
- (qthread.cpp) The note about GUI classes: Irrelevant to QThread,
and it's already mentioned elsewhere.
Change-Id: I6bc53cc22b929523f9976d2b920f94c02bd7273e
Reviewed-by: Geir Vattekar <geir.vattekar@digia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Default values should have mark-up to denote that they are code.
This commit changes:
-"property is true" to "property is \c true".
-"Returns true" to "Returns \c true".
-"property is false" to "property is \c false".
-"returns true" to "returns \c true".
-"returns false" to "returns \c false".
src/3rdparty and non-documentation instances were ignored.
Task-number: QTBUG-33360
Change-Id: Ie87eaa57af947caa1230602b61c5c46292a4cf4e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
qFlagLocation() uses a global char* array to transport source location
information from the connect() side to the metaobject side. The size
of the array is 2 (two), which just about suffices for a single connect()
statement.
Obviously, if more than one thread makes a (_any_) connection at the same
time, the data is useless and, worse, there's a data race.
The non-reentrancy of qFlagLocations() cannot and need not be fixed,
but use a per-thread flagged_locations array in QThreadData so threads
don't disturb each other.
Task-number: QTBUG-3680
Change-Id: If1797c60751f551694def69afee6fbe295bbe2d2
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Rationale: a wait on a condition-variable is usually a cancellation point.
On Posix, and probably in C++ at some point, a thread cancellation is
done by (a kind of) exception unwinding the stack. To ensure that
we call reserveThread() in all cases, wrap the function pair in a RAII
class. Even if we currently don't seem to support exceptions in QtCore,
this is low-hanging fruit, and no worse than what we had before.
Change-Id: Ifb0f428ea50f9ac12be14e620615f46e00d3dd91
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
The read from 'owner' for comparison with 'self' in QRecursiveMutexPrivate::lock()
is not synchronized with the write to 'owner' in the same function further down,
and neither operation is atomic.
Fix by making 'owner' an atomic pointer.
Change-Id: I186b88575589da0dce5827a1e17ceb4ce599ed02
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
- The "Concurrent Programming" page is an exact duplicate of the Qt Concurrent module landing
page.
- The "qtconcurrent intro" target is not referenced anywhere.
Change-Id: Ice9b4360783013fe972258ca54a0004be43b8766
Reviewed-by: Jerome Pasion <jerome.pasion@digia.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>
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>
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 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>
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>
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>
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>
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>
Andy Shaw
Thiago Macieira
Frederik Gladhorn
Yoann Lopes
Jani Heikkinen
Sze Howe Koh
Tobias Koenig
Marc Mutz
Nick Shaforostoff
Olivier Goffart
Tor Arne Vestbø
Gabriel de Dietrich
Nico Vertriest
Matti Paaso
Frederik Gladhorn
Adam Majer
Andrew Knight
David Faure
Eskil Abrahamsen Blomfeldt
Oswald Buddenhagen
Friedemann Kleint
Fatih Aşıcı
Jerome Pasion
Oliver Wolff
Kamil Trzcinski
Sergio Ahumada
Corentin Jabot
Jake Petroules
Stephen Kelly
Jan Kundrát
Axel Waggershauser