[quote=“syam”]Qt permet d’associer chaque objet avec un thread spécifique, dans lequel s’exécuteront tous les slots de cet objet appelés par un signal (un appel direct au slot se comportera comme s’il s’agissait d’une méthode normale, donc s’exécutera dans le thread de l’appelant).
Les signaux et les arguments pour le slot sont automatiquement dispatchés à chaque thread en fonction des besoins tout en garantissant la synchronisation entre threads.[/quote]
[quote=“syam”]Pour bien comprendre l’intérêt, il faut se rappeler que Qt n’est pas juste un toolkit graphique, mais a vocation à être une plate-forme complète pour faciliter la portabilité des applications.
Donc il y a toute une flopée de classes non-graphiques (au hasard : réseau, filesystem, …) qui sont concernées par ce mécanisme.
Exemple classique : toute la couche réseau va être associée à un (ou plusieurs) thread(s) donné(s), et ne communiquera avec le reste du programme que par signaux/slots.[/quote]
Je le sais parfaitement. C’est marrant de devoir ressortir ça pour expliquer alors qu’une ihm c’est de toute manière multithreadé de base par nécessité. Alors que justement les derniers serveurs utilisent plutôt de l’asynchronisme. 
Tu parle de coût en terme de facilité de développement j’espère. Parce que sinon tu t’es laissé bourré le mou par une plaquette publicitaire. Le parallélisme entraine en coût quoi qu’il arrive. Il y a de la synchronisation à mettre en place, déterminer si tu es optimiste ou pas, comment sont accéder tes ressources partagées, etc.
Mais ça m’intéresse beaucoup ce que tu dis. C’est le genre de truc dont j’avais l’impression de passer à coté. Tu veux dire que Qt va créer des threads, dispatcher les objets dans les threads et que lors du emit c’est le thread de l’objet du slot qui va s’exécuter ?
Faut que je dorme dessus pour y repenser (j’ai écris ce message ce matin et depuis j’attends d’avoir un peu de temps de cerveau libre pour y réfléchir) et comparer avec le pattern observer.
Merci beaucoup
