Prise en charge des threads dans les modules Qt

Les threads et le module SQL

Une connexion à une base de données ne doit être utilisée qu'au sein du thread qui l'a créée. Le transfert d'une connexion vers un autre thread peut être effectué à l'aide de la fonction ` QSqlDatabase::moveToThread()`.

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

Affichage dans les threads

QPainter peut être utilisé dans un thread pour dessiner sur les périphériques de dessin QImage, QPrinter, QPicture et (pour la plupart des plateformes) QPixmap. Le dessin sur les QWidgets n’ est pas pris en charge. Sous macOS, la boîte de dialogue de progression automatique ne s’affichera pas si vous effectuez l’impression depuis l’extérieur du thread de l’interface graphique.

Un nombre illimité de threads peut effectuer des opérations de dessin à un moment donné, mais un seul thread à la fois peut dessiner sur un périphérique de dessin donné. En d’autres termes, deux threads peuvent dessiner simultanément si chacun dessine sur des QImages distinctes, mais les deux threads ne peuvent pas dessiner simultanément sur le même QImage.

Les threads et le traitement du texte enrichi

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

Notez qu’une instance de ` QTextDocument ` créée dans le thread de l’interface graphique peut contenir des ressources d’image ` QPixmap `. Utilisez ` QTextDocument::clone()` pour créer une copie du document, puis transmettez cette copie à un autre thread pour un traitement ultérieur (tel que l’impression).

Les threads et le module SVG

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

Les threads et les classes à partage implicite

Qt utilise une optimisation appelée « partage implicite » pour bon nombre de ses classes de valeur, notamment QImage et QString. À partir de Qt 4, les classes à partage implicite peuvent être copiées en toute sécurité d’un thread à l’autre, comme n’importe quelle autre classe de valeur. Elles sont entièrement réentrantes. Le partage implicite est véritablement implicite.

Dans l’esprit de beaucoup, 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 utilise cependant un comptage atomique des références pour garantir l’intégrité des données partagées, évitant ainsi toute corruption potentielle du compteur de références.

Notez que le comptage atomique des références ne garantit pas la sécurité inter-threads. Un verrouillage approprié doit être utilisé lors du partage d’une instance d’une classe partagée implicitement entre plusieurs threads. Il s’agit là d’une exigence qui s’applique à toutes les classes réentrantes, qu’elles soient partagées ou non. Le comptage atomique des références garantit toutefois qu’un thread travaillant sur sa propre instance locale d’une classe partagée implicitement est sûr. Nous recommandons d’utiliser des signaux et des slots pour transmettre des données entre les threads, car cela peut se faire sans nécessiter de verrouillage explicite.

En résumé, les classes implicitement partagées dans Qt 4 sont véritablement partagées de manière implicite. Même dans les applications multithread, vous pouvez les utiliser en toute sécurité comme s’il s’agissait de classes simples, non partagées, réentrantes et basées sur des valeurs.