Le support des threads dans les modules Qt

Les threads ne sont pas uniformément supportés dans tous les modules de Qt.

Les threads et le module SQL

Une connexion ne peut être utilisée qu'à partir du thread qui l'a créé. Déplacer des connexions entre des threads ou créer des requêtes à partir d'un thread différent n'est pas supporté.

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

Peindre dans des threads

QPainter peut être utilisé dans un thread pour peindre sur les dispositifs de peinture QImage, QPrinter et QPicture. Peindre sur des QPixmap et QWidget n'est pas supporté. Sous Mac OS X, la boîte de dialogue de progression automatique ne sera pas affichée si vous êtes en train d'imprimer depuis un thread extérieur au thread de l'interface.

Plusieurs threads peuvent peindre simultanément. Cependant, un seul thread à la fois peut peindre sur un dispositif de peinture donné. En d'autres termes, deux threads peuvent peindre au même moment si chacun peint sur des objets QImage distincts, mais les deux threads ne peuvent pas peindre sur le même objet QImage en même temps.

Il faut noter que, sur les systèmes X11 qui ne supportent pas FontConfig, Qt ne peut pas afficher le texte en dehors du thread de l'interface. Vous pouvez utiliser la fonction QFontDatabase::supportsThreadedFontRendering() pour détecter si le rendu de police peut être utilisé en dehors du thread de l'interface ou pas.

Les threads et le traitement de texte riche

QTextDocument, QTextCursor, et toutes les classes liées sont ré-entrantes⁽¹⁾.

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

Les threads et le module SVG

Les classes QSvgGenerator et QSvgRenderer dans le module QtSvg sont ré-entrantes.

Les threads et les classes partagées implicitement

Qt utilise une optimisation appelée partage implicite pour de nombreuses classes de valeur, en particulier QImage et QString. Dès Qt 4, les classes partagées implicitement peuvent être copiées de façon sûre d'un thread à un autre, comme n'importe quelle classe de valeurs. Elles sont totalement ré-entrantes. Le partage implicite est réellement implicite.

Dans l'esprit des gens, le partage implicite et le multi-threading ne sont pas des concepts compatibles à cause de la façon dont le comptage de référence est en général effectué. Cependant, Qt utilise un comptage de référence atomique pour assurer l'intégrité des données partagées, évitant ainsi les corruptions potentielles du compteur de référence.

Notez que le comptage atomique des références ne garantit pas que le programme soit thread-safe⁽²⁾. Un verrouillage approprié doit être utilisé lors du partage entre plusieurs threads d'une instance de classe partagée implicitement. C'est la même condition appliquée à toutes les classes ré-entrantes, partagées ou non. Le comptage de référence atomique peut, cependant, garantir qu'un thread travaillant sur sa propre instance locale d'une classe partagée est sûr. Comme cela peut être réalisé sans aucun verrouillage explicite, nous recommandons d'utiliser les signaux et les slots pour passer des données à travers des threads.

Pour résumer, les classes partagées implicitement dans Qt 4 sont réellement partagées implicitement. Même dans les applications avec plusieurs threads, vous pouvez les utiliser de façon sûre, comme si elles étaient de simples classes à base de valeur, non-partagées et ré-entrantes.

Remerciements

Merci à Florent Renault pour la traduction, à Jonathan Courtois, à Thibaut Cuvelier ainsi qu'à Philippe Beaucart pour leur relecture !