/****************************************************************************
**
** Copyright (C) 2016 The Qt Company Ltd.
** Contact: https://www.qt.io/licensing/
**
** This file is part of the documentation of the Qt Toolkit.
**
** $QT_BEGIN_LICENSE:FDL$
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and The Qt Company. For licensing terms
** and conditions see https://www.qt.io/terms-conditions. For further
** information use the contact form at https://www.qt.io/contact-us.
**
** GNU Free Documentation License Usage
** Alternatively, this file may be used under the terms of the GNU Free
** Documentation License version 1.3 as published by the Free Software
** Foundation and appearing in the file included in the packaging of
** this file. Please review the following information to ensure
** the GNU Free Documentation License version 1.3 requirements
** will be met: https://www.gnu.org/licenses/fdl-1.3.html.
** $QT_END_LICENSE$
**
****************************************************************************/

/*!
    \group thread
    \brief How to develop multithreaded applications.
    \title Threading Classes

    These \l{Qt Core} classes provide threading support to applications.
    The \l{Thread Support in Qt} page covers how to use these classes.
*/

/*!
    \page threads.html
    \title Thread Support in Qt
    \ingroup qt-basic-concepts
    \brief A detailed discussion of thread handling in Qt.

    \ingroup frameworks-technologies

    \nextpage Multithreading Technologies in Qt

    Qt provides thread support in the form of platform-independent
    threading classes, a thread-safe way of posting events, and
    signal-slot connections across threads. This makes it easy to
    develop portable multithreaded Qt applications and take advantage
    of multiprocessor machines. Multithreaded programming is also a
    useful paradigm for performing time-consuming operations without
    freezing the user interface of an application.

    Earlier versions of Qt offered an option to build the library
    without thread support. Since Qt 4.0, threads are always enabled.

    \section1 Topics:

    These articles assume that the reader has basic knowledge about
    multithreaded applications.

    \list
    \li \l{The Threading Classes}
    \li \l{Multithreading Technologies in Qt}
    \li \l{Synchronizing Threads}
    \li \l{Reentrancy and Thread-Safety}
    \li \l{Threads and QObjects}
    \li \l{Thread-Support in Qt Modules}
    \endlist


    \section1 The Threading Classes

    These classes are relevant to threaded applications.

    \annotatedlist thread

\omit
    \list
    \li QThread provides the means to start a new thread.
    \li QThreadStorage provides per-thread data storage.
    \li QThreadPool manages a pool of threads that run QRunnable objects.
    \li QRunnable is an abstract class representing a runnable object.
    \li QMutex provides a mutual exclusion lock, or mutex.
    \li QMutexLocker is a convenience class that automatically locks
       and unlocks a QMutex.
    \li QReadWriteLock provides a lock that allows simultaneous read access.
    \li QReadLocker and QWriteLocker are convenience classes that automatically
       lock and unlock a QReadWriteLock.
    \li QSemaphore provides an integer semaphore (a generalization of a mutex).
    \li QWaitCondition provides a way for threads to go to sleep until
       woken up by another thread.
    \li QAtomicInt provides atomic operations on integers.
    \li QAtomicPointer provides atomic operations on pointers.
    \endlist
\endomit

    \note Qt's threading classes are implemented with native threading APIs;
    e.g., Win32 and pthreads. Therefore, they can be used with threads of the
    same native API.
*/

/*!
    \page threads-technologies.html
    \title Multithreading Technologies in Qt
    \ingroup qt-basic-concepts
    \brief An overview and comparison of different ways to use threads in Qt.

    \ingroup frameworks-technologies

    \previouspage Thread Support in Qt
    \nextpage Synchronizing Threads

    Qt offers many classes and functions for working with threads. Below are
    four different approaches that Qt programmers can use to implement
    multithreaded applications.


    \section1 QThread: Low-Level API with Optional Event Loops

    QThread is the foundation of all thread control in Qt. Each QThread
    instance represents and controls one thread.

    QThread can either be instantiated directly or subclassed. Instantiating a
    QThread provides a parallel event loop, allowing QObject slots to be invoked
    in a secondary thread. Subclassing a QThread allows the application to initialize
    the new thread before starting its event loop, or to run parallel code
    without an event loop.

    See the \l{QThread}{QThread class reference} and the \l{Threading and
    Concurrent Programming Examples}{threading examples} for demonstrations on
    how to use QThread.


    \section1 QThreadPool and QRunnable: Reusing Threads

    Creating and destroying threads frequently can be expensive. To reduce this
    overhead, existing threads can be reused for new tasks. QThreadPool is a
    collection of reuseable QThreads.

    To run code in one of a QThreadPool's threads, reimplement QRunnable::run()
    and instantiate the subclassed QRunnable. Use QThreadPool::start() to put
    the QRunnable in the QThreadPool's run queue. When a thread becomes available,
    the code within QRunnable::run() will execute in that thread.

    Each Qt application has a global thread pool, which is accessible through
    QThreadPool::globalInstance(). This global thread pool automatically maintains
    an optimal number of threads based on the number of cores in the CPU. However,
    a separate QThreadPool can be created and managed explicitly.


    \section1 Qt Concurrent: Using a High-level API

    The \l{Qt Concurrent} module provides high-level functions that deal with some
    common parallel computation patterns: map, filter, and reduce. Unlike using
    QThread and QRunnable, these functions never require the use of \l{Synchronizing
    Threads#Low-Level Synchronization Primitives}{low-level threading primitives}
    such as mutexes or semaphores. Instead, they return a QFuture object which can
    be used to retrieve the functions' results when they are ready. QFuture can
    also be used to query computation progress and to pause/resume/cancel the
    computation. For convenience, QFutureWatcher enables interactions with
    \l{QFuture}s via signals and slots.

    \l{Qt Concurrent}'s map, filter and reduce algorithms automatically distribute
    computation across all available processor cores, so applications written today
    will continue to scale when deployed later on a system with more cores.

    This module also provides the \l {QtConcurrent::run}() function, which can run any
    function in another thread. However, \l {QtConcurrent::run}() only supports a subset
    of features available to the map, filter and reduce functions. The QFuture
    can be used to retrieve the function's return value and to check if the thread
    is running. However, a call to \l{QtConcurrent::run}() uses one thread only, cannot
    be paused/resumed/canceled, and cannot be queried for progress.

    See the \l{Qt Concurrent} module documentation for details on the individual functions.


    \section1 WorkerScript: Threading in QML

    The WorkerScript QML type lets JavaScript code run in parallel with the GUI
    thread.

    Each WorkerScript instance can have one \c{.js} script attached to it. When
    \l {QtQml.WorkerScript::WorkerScript::sendMessage()}{WorkerScript.sendMessage}() is
    called, the script will run in a separate thread (and a separate
    \l{QQmlContext}{QML context}). When the script finishes running, it can
    send a reply back to the GUI thread which will invoke the
    \l {QtQml.WorkerScript::WorkerScript::message()}{WorkerScript.onMessage}()
    signal handler.

    Using a WorkerScript is similar to using a worker QObject that has been moved
    to another thread. Data is transferred between threads via signals.

    See the WorkerScript documentation for details on how to implement the script,
    and for a list of data types that can be passed between threads.


    \section1 Choosing an Appropriate Approach

    As demonstrated above, Qt provides different solutions for developing threaded
    applications. The right solution for a given application depends on the purpose
    of the new thread and the thread's lifetime. Below is a comparison of Qt's
    threading technologies, followed by recommended solutions for some example use cases.

    \section2 Comparison of Solutions

    \table
    \header
        \li Feature
        \li QThread
        \li QRunnable and QThreadPool
        \li \l {QtConcurrent::run}()
        \li Qt Concurrent (Map, Filter, Reduce)
        \li WorkerScript
    \row
        \li Language
        \li C++
        \li C++
        \li C++
        \li C++
        \li QML
    \row
        \li Thread priority can be specified
        \li Yes
        \li Yes
        \li
        \li
        \li
    \row
        \li Thread can run an event loop
        \li Yes
        \li
        \li
        \li
        \li
    \row
        \li Thread can receive data updates through signals
        \li Yes (received by a worker QObject)
        \li
        \li
        \li
        \li Yes (received by WorkerScript)
    \row
        \li Thread can be controlled using signals
        \li Yes (received by QThread)
        \li
        \li
        \li Yes (received by QFutureWatcher)
        \li
    \row
        \li Thread can be monitored through a QFuture
        \li
        \li
        \li Partially
        \li Yes
        \li
    \row
        \li Built-in ability to pause/resume/cancel
        \li
        \li
        \li
        \li Yes
        \li
    \endtable


    \section2 Example Use Cases

    \table
    \header
        \li Lifetime of thread
        \li Operation
        \li Solution
    \row
        \li One call
        \li Run a new linear function within another thread, optionally with progress
            updates during the run.
        \li Qt provides different solutions:
            \list
              \li Place the function in a reimplementation of QThread::run() and
                  start the QThread. Emit signals to update progress. OR
              \li Place the function in a reimplementation of QRunnable::run() and
                  add the QRunnable to a QThreadPool. Write to a \l{Synchronizing
                  Threads}{thread-safe variable} to update progress. OR
              \li Run the function using \l {QtConcurrent::run}(). Write to a \l{Synchronizing
                  Threads}{thread-safe variable} to update progress.
            \endlist
    \row
        \li One call
        \li Run an existing function within another thread and get its return value.
        \li Run the function using \l{QtConcurrent::run}(). Have a QFutureWatcher emit
            the \l{QFutureWatcher::}{finished()} signal when the function has
            returned, and call QFutureWatcher::result() to get the function's return
            value.
    \row
        \li One call
        \li Perform an operation on all items of a container, using all available
            cores. For example, producing thumbnails from a list of images.
        \li Use Qt Concurrent's \l{QtConcurrent::filter}() function to select
            container elements, and the \l{QtConcurrent::map}() function to apply
            an operation to each element. To fold the output into a single result,
            use \l{QtConcurrent::filteredReduced}() and
            \l{QtConcurrent::mappedReduced}() instead.
    \row
        \li One call/Permanent
        \li Perfrom a long computation in a pure QML application, and update the GUI
            when the results are ready.
        \li Place the computation code in a \c{.js} script and attach it to a
            WorkerScript instance. Call
            \l{QtQml.WorkerScript::WorkerScript::sendMessage()}
            {WorkerScript.sendMessage}() to start the computation in a new
            thread. Let the script call sendMessage() too, to pass the result
            back to the GUI thread. Handle the result in \c onMessage and
            update the GUI there.
    \row
        \li Permanent
        \li Have an object living in another thread that can perform different
            tasks upon request and/or can receive new data to work with.
        \li Subclass a QObject to create a worker. Instantiate this worker object
            and a QThread. Move the worker to the new thread. Send commands or
            data to the worker object over queued signal-slot connections.
    \row
        \li Permanent
        \li Repeatedly perform an expensive operation in another thread, where the
            thread does not need to receive any signals or events.
        \li Write the infinite loop directly within a reimplementation of QThread::run().
            Start the thread without an event loop. Let the thread emit signals to
            send data back to the GUI thread.
    \endtable
*/

/*!
    \page threads-synchronizing.html
    \title Synchronizing Threads

    \previouspage Multithreading Technologies in Qt
    \nextpage Reentrancy and Thread-Safety

    While the purpose of threads is to allow code to run in parallel,
    there are times where threads must stop and wait for other
    threads. For example, if two threads try to write to the same
    variable simultaneously, the result is undefined. The principle of
    forcing threads to wait for one another is called \e{mutual exclusion}.
    It is a common technique for protecting shared resources such as data.

    Qt provides low-level primitives as well as high-level mechanisms
    for synchronizing threads.

    \section1 Low-Level Synchronization Primitives

    QMutex is the basic class for enforcing mutual exclusion. A thread
    locks a mutex in order to gain access to a shared resource. If a second
    thread tries to lock the mutex while it is already locked, the second
    thread will be put to sleep until the first thread completes its task
    and unlocks the mutex.

    QReadWriteLock is similar to QMutex, except that it distinguishes
    between "read" and "write" access. When a piece of data is not being
    written to, it is safe for multiple threads to read from it simultaneously.
    A QMutex forces multiple readers to take turns to read shared data, but a
    QReadWriteLock allows simultaneous reading, thus improving parallelism.

    QSemaphore is a generalization of QMutex that protects a certain
    number of identical resources. In contrast, a QMutex protects
    exactly one resource. The \l{Semaphores Example} shows a typical application
    of semaphores: synchronizing access to a circular buffer between a producer
    and a consumer.

    QWaitCondition synchronizes threads not by enforcing mutual exclusion but by
    providing a \e{condition variable}. While the other primitives make threads
    wait until a resource is unlocked, QWaitCondition makes threads wait until a
    particular condition has been met. To allow the waiting threads to proceed,
    call \l{QWaitCondition::wakeOne()}{wakeOne()} to wake one randomly
    selected thread or \l{QWaitCondition::wakeAll()}{wakeAll()} to wake them all
    simultaneously. The \l{Wait Conditions Example} shows how to solve the
    producer-consumer problem using QWaitCondition instead of QSemaphore.

    \note Qt's synchronization classes rely on the use of properly
    aligned pointers. For instance, you cannot use packed classes with
    MSVC.

    These synchronization classes can be used to make a method thread safe.
    However, doing so incurs a performance penalty, which is why most Qt methods
    are not made thread safe.

    \section2 Risks

    If a thread locks a resource but does not unlock it, the application may
    freeze because the resource will become permanently unavailable to other threads.
    This can happen, for example, if an exception is thrown and forces the current
    function to return without releasing its lock.

    Another similar scenario is a \e{deadlock}. For example, suppose that
    thread A is waiting for thread B to unlock a resource. If thread B is also
    waiting for thread A to unlock a different resource, then both threads will
    end up waiting forever, so the application will freeze.

    \section2 Convenience classes

    QMutexLocker, QReadLocker and QWriteLocker are convenience classes that make it
    easier to use QMutex and QReadWriteLock. They lock a resource when they are
    constructed, and automatically unlock it when they are destroyed. They are
    designed to simplify code that use QMutex and QReadWriteLock, thus reducing
    the chances that a resource becomes permanently locked by accident.

    \section1 High-Level Event Queues

    Qt's \l{The Event System}{event system} is very useful for inter-thread
    communication. Every thread may have its own event loop. To call a slot (or
    any \l{Q_INVOKABLE}{invokable} method) in another thread, place that call in
    the target thread's event loop. This lets the target thread finish its current
    task before the slot starts running, while the original thread continues
    running in parallel.

    To place an invocation in an event loop, make a queued \l{Signals & Slots}
    {signal-slot} connection. Whenever the signal is emitted, its arguments will
    be recorded by the event system. The thread that the signal receiver
    \l{QObject#Thread Affinity}{lives in} will then run the slot. Alternatively,
    call QMetaObject::invokeMethod() to achieve the same effect without signals.
    In both cases, a \l{Qt::QueuedConnection}{queued connection} must be used
    because a \l{Qt::DirectConnection}{direct connection} bypasses the event
    system and runs the method immediately in the current thread.

    There is no risk of deadlocks when using the event system for thread
    synchronization, unlike using low-level primitives. However, the event system
    does not enforce mutual exclusion. If invokable methods access shared data,
    they must still be protected with low-level primitives.

    Having said that, Qt's event system, along with \l{Implicit Sharing}{implicitly
    shared} data structures, offers an alternative to traditional thread locking.
    If signals and slots are used exclusively and no variables are shared between
    threads, a multithreaded program can do without low-level primitives altogether.

    \sa QThread::exec(), {Threads and QObjects}
*/

/*!
    \page threads-reentrancy.html
    \title Reentrancy and Thread-Safety

    \keyword reentrant
    \keyword thread-safe

    \previouspage Synchronizing Threads
    \nextpage Threads and QObjects

    Throughout the documentation, the terms \e{reentrant} and
    \e{thread-safe} are used to mark classes and functions to indicate
    how they can be used in multithread applications:

    \list
    \li A \e thread-safe function can be called simultaneously from
       multiple threads, even when the invocations use shared data,
       because all references to the shared data are serialized.
    \li A \e reentrant function can also be called simultaneously from
       multiple threads, but only if each invocation uses its own data.
    \endlist

    Hence, a \e{thread-safe} function is always \e{reentrant}, but a
    \e{reentrant} function is not always \e{thread-safe}.

    By extension, a class is said to be \e{reentrant} if its member
    functions can be called safely from multiple threads, as long as
    each thread uses a \e{different} instance of the class. The class
    is \e{thread-safe} if its member functions can be called safely
    from multiple threads, even if all the threads use the \e{same}
    instance of the class.

    \note Qt classes are only documented as \e{thread-safe} if they
    are intended to be used by multiple threads. If a function is not
    marked as thread-safe or reentrant, it should not be used from
    different threads. If a class is not marked as thread-safe or
    reentrant then a specific instance of that class should not be
    accessed from different threads.

    \section1 Reentrancy

    C++ classes are often reentrant, simply because they only access
    their own member data. Any thread can call a member function on an
    instance of a reentrant class, as long as no other thread can call
    a member function on the \e{same} instance of the class at the
    same time. For example, the \c Counter class below is reentrant:

    \snippet snippets/threads/threads.cpp 3
    \snippet snippets/threads/threads.cpp 4

    The class isn't thread-safe, because if multiple threads try to
    modify the data member \c n, the result is undefined. This is
    because the \c ++ and \c -- operators aren't always atomic.
    Indeed, they usually expand to three machine instructions:

    \list 1
    \li Load the variable's value in a register.
    \li Increment or decrement the register's value.
    \li Store the register's value back into main memory.
    \endlist

    If thread A and thread B load the variable's old value
    simultaneously, increment their register, and store it back, they
    end up overwriting each other, and the variable is incremented
    only once!

    \section1 Thread-Safety

    Clearly, the access must be serialized: Thread A must perform
    steps 1, 2, 3 without interruption (atomically) before thread B
    can perform the same steps; or vice versa. An easy way to make
    the class thread-safe is to protect all access to the data
    members with a QMutex:

    \snippet snippets/threads/threads.cpp 5
    \snippet snippets/threads/threads.cpp 6

    The QMutexLocker class automatically locks the mutex in its
    constructor and unlocks it when the destructor is invoked, at the
    end of the function. Locking the mutex ensures that access from
    different threads will be serialized. The \c mutex data member is
    declared with the \c mutable qualifier because we need to lock
    and unlock the mutex in \c value(), which is a const function.

    \section1 Notes on Qt Classes

    Many Qt classes are \e{reentrant}, but they are not made
    \e{thread-safe}, because making them thread-safe would incur the
    extra overhead of repeatedly locking and unlocking a QMutex. For
    example, QString is reentrant but not thread-safe. You can safely
    access \e{different} instances of QString from multiple threads
    simultaneously, but you can't safely access the \e{same} instance
    of QString from multiple threads simultaneously (unless you
    protect the accesses yourself with a QMutex).

    Some Qt classes and functions are thread-safe. These are mainly
    the thread-related classes (e.g. QMutex) and fundamental functions
    (e.g. QCoreApplication::postEvent()).

    \note Terminology in the multithreading domain isn't entirely
    standardized. POSIX uses definitions of reentrant and thread-safe
    that are somewhat different for its C APIs. When using other
    object-oriented C++ class libraries with Qt, be sure the
    definitions are understood.
*/

/*!
    \page threads-qobject.html
    \title Threads and QObjects

    \previouspage Reentrancy and Thread Safety
    \nextpage Thread-Support in Qt Modules

    QThread inherits QObject. It emits signals to indicate that the
    thread started or finished executing, and provides a few slots as
    well.

    More interesting is that \l{QObject}s can be used in multiple
    threads, emit signals that invoke slots in other threads, and
    post events to objects that "live" in other threads. This is
    possible because each thread is allowed to have its own event
    loop.

    \section1 QObject Reentrancy

    QObject is reentrant. Most of its non-GUI subclasses, such as
    QTimer, QTcpSocket, QUdpSocket and QProcess, are also
    reentrant, making it possible to use these classes from multiple
    threads simultaneously. Note that these classes are designed to be
    created and used from within a single thread; creating an object
    in one thread and calling its functions from another thread is not
    guaranteed to work. There are three constraints to be aware of:

    \list
    \li \e{The child of a QObject must always be created in the thread
       where the parent was created.} This implies, among other
       things, that you should never pass the QThread object (\c
       this) as the parent of an object created in the thread (since
       the QThread object itself was created in another thread).

    \li \e{Event driven objects may only be used in a single thread.}
       Specifically, this applies to the \l{timers.html}{timer
       mechanism} and the \l{QtNetwork}{network module}. For example,
       you cannot start a timer or connect a socket in a thread that
       is not the \l{QObject::thread()}{object's thread}.

    \li \e{You must ensure that all objects created in a thread are
       deleted before you delete the QThread.} This can be done
       easily by creating the objects on the stack in your
       \l{QThread::run()}{run()} implementation.
    \endlist

    Although QObject is reentrant, the GUI classes, notably QWidget
    and all its subclasses, are not reentrant. They can only be used
    from the main thread. As noted earlier, QCoreApplication::exec()
    must also be called from that thread.

    In practice, the impossibility of using GUI classes in other
    threads than the main thread can easily be worked around by
    putting time-consuming operations in a separate worker thread and
    displaying the results on screen in the main thread when the
    worker thread is finished. This is the approach used for
    implementing the \l{Mandelbrot Example} and
    the \l{Blocking Fortune Client Example}.

    In general, creating QObjects before the QApplication is not supported
    and can lead to weird crashes on exit, depending on the platform.
    This means static instances of QObject are also not supported. A
    properly structured single or multi-threaded application should make
    the QApplication be the first created, and last destroyed QObject.

    \section1 Per-Thread Event Loop

    Each thread can have its own event loop. The initial thread starts
    its event loop using QCoreApplication::exec(), or for
    single-dialog GUI applications, sometimes QDialog::exec().
    Other threads can start an event loop using QThread::exec().
    Like QCoreApplication, QThread provides an \l{QThread::exit()}{exit(int)}
    function and a \l{QThread::quit()}{quit()} slot.

    An event loop in a thread makes it possible for the thread to use
    certain non-GUI Qt classes that require the presence of an event
    loop (such as QTimer, QTcpSocket, and QProcess). It also makes it
    possible to connect signals from any threads to slots of a
    specific thread. This is explained in more detail in the
    \l{Signals and Slots Across Threads} section below.

    \image threadsandobjects.png Threads, objects, and event loops

    A QObject instance is said to \e live in the thread in which it
    is created. Events to that object are dispatched by that thread's
    event loop. The thread in which a QObject lives is available using
    QObject::thread().

    The QObject::moveToThread() function changes the thread affinity for
    an object and its children (the object cannot be moved if it has a
    parent).

    Calling \c delete on a QObject from a thread other than the one
    that \e owns the object (or accessing the object in other ways) is
    unsafe, unless you guarantee that the object isn't processing
    events at that moment. Use QObject::deleteLater() instead, and a
    \l{QEvent::DeferredDelete}{DeferredDelete} event will be posted,
    which the event loop of the object's thread will eventually pick
    up. By default, the thread that \e owns a QObject is the thread
    that \e creates the QObject, but not after QObject::moveToThread()
    has been called.

    If no event loop is running, events won't be delivered to the
    object. For example, if you create a QTimer object in a thread but
    never call \l{QThread::exec()}{exec()}, the QTimer will never emit
    its \l{QTimer::timeout()}{timeout()} signal. Calling
    \l{QObject::deleteLater()}{deleteLater()} won't work
    either. (These restrictions apply to the main thread as well.)

    You can manually post events to any object in any thread at any
    time using the thread-safe function
    QCoreApplication::postEvent(). The events will automatically be
    dispatched by the event loop of the thread where the object was
    created.

    Event filters are supported in all threads, with the restriction
    that the monitoring object must live in the same thread as the
    monitored object. Similarly, QCoreApplication::sendEvent()
    (unlike \l{QCoreApplication::postEvent()}{postEvent()}) can only
    be used to dispatch events to objects living in the thread from
    which the function is called.

    \section1 Accessing QObject Subclasses from Other Threads

    QObject and all of its subclasses are not thread-safe. This
    includes the entire event delivery system. It is important to keep
    in mind that the event loop may be delivering events to your
    QObject subclass while you are accessing the object from another
    thread.

    If you are calling a function on an QObject subclass that doesn't
    live in the current thread and the object might receive events,
    you must protect all access to your QObject subclass's internal
    data with a mutex; otherwise, you may experience crashes or other
    undesired behavior.

    Like other objects, QThread objects live in the thread where the
    object was created -- \e not in the thread that is created when
    QThread::run() is called. It is generally unsafe to provide slots
    in your QThread subclass, unless you protect the member variables
    with a mutex.

    On the other hand, you can safely emit signals from your
    QThread::run() implementation, because signal emission is
    thread-safe.

    \section1 Signals and Slots Across Threads

    Qt supports these signal-slot connection types:

    \list

    \li \l{Qt::AutoConnection}{Auto Connection} (default) If the signal is
       emitted in the thread which the receiving object has affinity then
       the behavior is the same as the Direct Connection. Otherwise,
       the behavior is the same as the Queued Connection."

    \li \l{Qt::DirectConnection}{Direct Connection} The slot is invoked
       immediately, when the signal is emitted. The slot is executed
       in the emitter's thread, which is not necessarily the
       receiver's thread.

    \li \l{Qt::QueuedConnection}{Queued Connection} The slot is invoked
       when control returns to the event loop of the receiver's
       thread. The slot is executed in the receiver's thread.

    \li \l{Qt::BlockingQueuedConnection}{Blocking Queued Connection}
       The slot is invoked as for the Queued Connection, except the
       current thread blocks until the slot returns. \note Using this
       type to connect objects in the same thread will cause deadlock.

    \li \l{Qt::UniqueConnection}{Unique Connection} The behavior is the
       same as the Auto Connection, but the connection is made only if
       it does not duplicate an existing connection. i.e., if the same
       signal is already connected to the same slot for the same pair
       of objects, then the connection is not made and connect()
       returns \c false.

    \endlist

    The connection type can be specified by passing an additional
    argument to \l{QObject::connect()}{connect()}. Be aware that
    using direct connections when the sender and receiver live in
    different threads is unsafe if an event loop is running in the
    receiver's thread, for the same reason that calling any function
    on an object living in another thread is unsafe.

    QObject::connect() itself is thread-safe.

    The \l{Mandelbrot Example} uses a queued
    connection to communicate between a worker thread and the main
    thread. To avoid freezing the main thread's event loop (and, as a
    consequence, the application's user interface), all the
    Mandelbrot fractal computation is done in a separate worker
    thread. The thread emits a signal when it is done rendering the
    fractal.

    Similarly, the \l{Blocking Fortune Client Example} uses a separate
    thread for communicating with a TCP server asynchronously.
*/

/*!
    \page threads-modules.html
    \title Thread-Support in Qt Modules

    \previouspage Threads and QObjects

    \section1 Threads and the SQL Module

    A connection can only be used from within the thread that created it.
    Moving connections between threads or creating queries from a different
    thread is not supported.

    In addition, the third party libraries used by the QSqlDrivers can impose
    further restrictions on using the SQL Module in a multithreaded program.
    Consult the manual of your database client for more information

    \section1 Painting in Threads

    QPainter can be used in a thread to paint onto QImage, QPrinter, and
    QPicture paint devices. Painting onto QPixmaps and QWidgets is \e not
    supported. On \macos the automatic progress dialog will not be
    displayed if you are printing from outside the GUI thread.

    Any number of threads can paint at any given time, however only
    one thread at a time can paint on a given paint device. In other
    words, two threads can paint at the same time if each paints onto
    separate QImages, but the two threads cannot paint onto the same
    QImage at the same time.

    \section1 Threads and Rich Text Processing

    The QTextDocument, QTextCursor, and \l{richtext.html}{all related classes} are reentrant.

    Note that a QTextDocument instance created in the GUI thread may
    contain QPixmap image resources. Use QTextDocument::clone() to
    create a copy of the document, and pass the copy to another thread for
    further processing (such as printing).

    \section1 Threads and the SVG Module

    The QSvgGenerator and QSvgRenderer classes in the QtSvg module
    are reentrant.

    \section1 Threads and Implicitly Shared Classes

    Qt uses an optimization called \l{implicit sharing} for many of
    its value class, notably QImage and QString. Beginning with Qt 4,
    implicit shared classes can safely be copied across threads, like
    any other value classes. They are fully
    \l{Reentrancy and Thread-Safety}{reentrant}. The implicit sharing
    is really \e implicit.

    In many people's minds, implicit sharing and multithreading are
    incompatible concepts, because of the way the reference counting
    is typically done. Qt, however, uses atomic reference counting to
    ensure the integrity of the shared data, avoiding potential
    corruption of the reference counter.

    Note that atomic reference counting does not guarantee
    \l{Reentrancy and Thread-Safety}{thread-safety}. Proper locking should be used
    when sharing an instance of an implicitly shared class between
    threads. This is the same requirement placed on all
    \l{Reentrancy and Thread-Safety}{reentrant} classes, shared or not. Atomic reference
    counting does, however, guarantee that a thread working on its
    own, local instance of an implicitly shared class is safe. We
    recommend using \l{Signals and Slots Across Threads}{signals and
    slots} to pass data between threads, as this can be done without
    the need for any explicit locking.

    To sum it up, implicitly shared classes in Qt 4 are really \e
    implicitly shared. Even in multithreaded applications, you can
    safely use them as if they were plain, non-shared, reentrant
    value-based classes.
*/