Thread-Support in Qt Modules[Qt 5.7.0]

http://doc.qt.io/qt-5/threads-modules.html

Contents

• Threads and the SQL Module
• Painting in Threads
• Threads and Rich Text Processing
• Threads and the SVG Module
• Threads and Implicitly Shared Classes

Thread-Support in Qt Modules

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

Painting in Threads

QPainter can be used in a thread to paint ontoQImage,QPrinter, andQPicture paint devices. Painting onto QPixmaps and QWidgets isnot supported.On OS X 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.

Threads and Rich Text Processing

The QTextDocument, QTextCursor, and all related classes are reentrant.

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

Threads and the SVG Module

The QSvgGenerator and QSvgRenderer classes in theQtSvg module are reentrant.

Threads and Implicitly Shared Classes

Qt uses an optimization calledimplicit sharing for many of its value class, notablyQImage andQString. Beginning with Qt 4, implicit shared classes can safely be copied across threads, like any other value classes. They are fullyreentrant. The implicit sharing is reallyimplicit.

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 guaranteethread-safety. Proper locking should be used when sharing an instance of an implicitly shared class between threads. This is the same requirement placed on allreentrant 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 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 reallyimplicitly shared. Even in multithreaded applications, you can safely use them as if they were plain, non-shared, reentrant value-based classes.