La gestion des threads dans Qt est simple mais elle mérite quelques explications car elle engendre souvent des problèmes conceptuels chez les développeurs peu expérimentés en Qt. Faisons le point.
Une question que j’aborde fréquemment lors de mes séminaires de formation est celle des threads dans Qt. Celle-ci me semble importante car, lorsque je dois intervenir sur des projets bloqués je constate souvent que l’origine du problème est liée à une incompréhension du fonctionnement des threads dans Qt.
Le développement multiplateformes
Qt est compatible avec un grand nombre de systèmes d’exploitation et d’architectures. Sa device est « Code once, deploy everywhere », soit en français « codez une fois, déployez partout ».
Pourtant, selon l’architecture et le système d’exploitation sur lequel l’application tourne, la gestion des threads peut être (radicalement) différente. Sous les systèmes d’exploitation Windows, c’est Win32 qui gère les threads historiquement. Sous les systèmes Unix (pour ceux que je connais) c’est pthreads, qui est une implantation des threads POSIX. Je n’approfondirai pas le sujet mais sachez que ces deux spécifications sont très différentes.
Sous Windows, vous pouvez compiler une application en utilisant principalement deux environnements de compilation : Microsoft Visual Studio et GNU GCC. Le premier utilise les threads Win32 et le second utilise pthreads. Sous GNU/Linux et macOS c’est uniquement pthreads.
Pourtant, quand vous utilisez la classe QThread, c’est la même quel que soit le système d’exploitation ciblé, et votre application fonctionnera de la même manière partout.
Un début de réponse est que la classe QThread n’est pas un thread. C’est un contrôleur de threads. Elle permet de démarrer, contrôler et stopper un thread, celui-ci étant bel et bien géré par la bibliothèque système sou-jacente (Win32 ou pthreads). Il s’agit donc d’une habile abtraction. Je dis habile car elle son utilisation est d’une simplicité déconcertante. Tellement que son utilisation est excessive dans la plupart des projets que je rencontre, de mon point de vue.
Faisons donc le tour de ce qui me semble être de bonnes et de mauvaises raisons pour intégrer des threads dans sa conception. J’insiste d’ores et déjà sur le fait que cette décision doit être prise à la conception et non pendant le développement, j’y reviendrai (lourdement).
Si vous souhaitez être notifié lorsqu'un nouvel article est publié, abonnez-vous à notre newsletter et vous recevrez un email dès qu'un article sera publié.
