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

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.

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.

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 classes QSvgGenerator et QSvgRenderer dans le module QtSvg sont ré-entrantes.

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.

Merci à <!greattux!> pour la traduction, à <!johnlamericain!>, à <!dourouc!> ainsi qu’à <!hornetbzz!> pour leur relecture !