Les coutures de 2 ms me semblent suspectes. Les gens ont lu et écrit des ports série à 19200 bauds pendant des années (par exemple sur du matériel 486) sans surcharger le cpu. Peut-être que votre approche est erronée.
Quelle API utilisez-vous pour accéder au port? J'ai l'impression que vous les interrogez, si l'API prend en charge les lectures bloquées et écrit cela serait une bien meilleure approche. Le plus simple serait alors de mettre la lecture et l'écriture dans leur propre thread, et d'utiliser des lectures bloquantes dans une boucle, alors votre thread ne sera occupé que s'il y a des données à lire et que vous le traitez. Votre application doit savoir quand elle doit écrire, donc le bon thread doit attendre sur une variable de condition, quand les données sont disponibles, cette condition est déclenchée pour réveiller le thread d'écriture. Il est probablement plus facile d'utiliser des approches monothread car je suis sûr que les premières applications à lire et à écrire sur les ports série (par exemple x modem) n'étaient pas multithread, mais je ne les connais pas mais elles devraient être documentées dans l'API que vous utilisez.
Vos discussions sont-elles très occupées, avec ces minuteries? Il peut exister d'autres moyens de conserver les threads actifs. – bua
bua: Eh bien, je n'utilise pas les threads directement. Si Qt les utilise derrière la scène, je ne suis pas au courant. J'avais l'impression que cela faisait simplement une boucle dans le fil principal et que tout le calendrier était là. – Scott
votre impression est correcte en ce qui concerne le fil principal. est-il possible pour vous d'annuler certains timers pour avoir une idée de ceux qui prennent du temps? Je ne pense pas que ce soit le nombre de minuteurs ou l'intervalle qui prend du temps, c'est plus probable que les choses que vous faites en eux. –