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 !