Support des threads dans les modules Qt

Les threads et le module SQL

Une connexion à une base de données ne peut être utilisée qu'à l'intérieur du thread qui l'a créée. Le déplacement d'une connexion dans un autre thread peut être effectué à l'aide de QSqlDatabase::moveToThread().

En outre, les bibliothèques tierces utilisées par les pilotes QSqlDrivers peuvent imposer des restrictions supplémentaires à l'utilisation du module SQL dans un programme multithread. Consultez le manuel de votre client de base de données pour plus d'informations.

Peinture dans les threads

QPainter Le module QSqlDriver peut être utilisé dans un thread pour peindre sur QImage, QPrinter, QPicture et (pour la plupart des plates-formes) QPixmap. La peinture sur des QWidgets n' est pas prise en charge. Sous macOS, la boîte de dialogue de progression automatique ne s'affichera pas si vous imprimez depuis l'extérieur du fil d'exécution de l'interface graphique.

Un nombre illimité de threads peut peindre à tout moment, mais un seul thread à la fois peut peindre sur un périphérique de peinture donné. En d'autres termes, deux threads peuvent peindre en même temps si chacun peint sur des QImages séparées, mais les deux threads ne peuvent pas peindre sur le même QImage en même temps.

Threads et traitement de texte enrichi

Les classes QTextDocument, QTextCursor et toutes les classes apparentées sont réentrantes.

Notez qu'une instance QTextDocument créée dans le thread GUI peut contenir des ressources d'images QPixmap. Utilisez QTextDocument::clone() pour créer une copie du document, et passez la copie à un autre thread pour un traitement ultérieur (comme l'impression).

Les threads et le module SVG

Les classes QSvgGenerator et QSvgRenderer du module QtSvg sont réentrantes.

Threads et classes partagées implicitement

Qt XML utilise une optimisation appelée partage implicite pour un grand nombre de ses classes de valeurs, notamment QImage et QString. À partir de Qt 4, les classes partagées implicitement peuvent être copiées en toute sécurité entre les threads, comme n'importe quelle autre classe de valeur. Elles sont entièrement réentrantes. Le partage implicite est vraiment implicite.

Dans l'esprit de nombreuses personnes, le partage implicite et le multithreading sont des concepts incompatibles, en raison de la manière dont le comptage des références est généralement effectué. Qt, cependant, utilise le comptage de référence atomique pour garantir l'intégrité des données partagées, en évitant la corruption potentielle du compteur de référence.

Notez que le comptage atomique des références ne garantit pas la sécurité des threads. Un verrouillage approprié doit être utilisé lors du partage d'une instance d'une classe implicitement partagée entre les threads. Il s'agit de la même exigence que pour toutes les classes réentrantes, partagées ou non. Le comptage atomique des références garantit cependant qu'un thread travaillant sur sa propre instance locale d'une classe implicitement partagée est sûr. Nous recommandons l'utilisation de signaux et de slots pour transmettre des données entre les threads, car cela peut être fait sans nécessiter de verrouillage explicite.

En résumé, les classes implicitement partagées dans Qt 4 sont vraiment implicitement partagées. Même dans les applications multithread, vous pouvez les utiliser en toute sécurité comme s'il s'agissait de classes basées sur des valeurs, non partagées et réentrantes.