Que puis-je utiliser pour remplacer le sommeil et l'USLEEP dans mon application QT?

La raison pour laquelle le sommeil est une mauvaise idée dans la programmation basée sur les événements est que la programmation basée sur les événements est effectivement une forme sur le multitâche non préventif. En appelant le sommeil, vous empêchez tout autre événement devenant actif et en bloquant donc le traitement du fil.

Dans un scénario de réponse de requête pour les paquets UDP, envoyez la demande et attendez immédiatement la réponse. QT a de bonnes aptituées à la prise qui garantira que la prise ne bloque pas en attendant l'événement. L'événement viendra quand il viendra. Dans votre cas, le QSocket :: ReadReady Signal est votre ami.

Si vous souhaitez planifier un événement pendant un moment donné, utilisez Qticer. Cela garantira que d'autres événements ne sont pas bloqués.

Je ne sais pas comment le QTS gère les événements interne, mais sur la plupart des systèmes au niveau le plus bas, la vie d'application va comme suit: le code de thread principal est essentiellement une boucle (la boucle de message ), dans lequel, à chaque itération, l'application appelle une fonction qui lui donne un nouveau message; Habituellement, cette fonction bloque, c'est-à-dire s'il n'y a pas de messages, la fonction ne renvoie pas et que l'application est arrêtée.

Chaque fois que la fonction renvoie, l'application dispose d'un nouveau message à traiter, qui a généralement un destinataire (la fenêtre auquel est envoyée), une signification (le code de message, par exemple le pointeur de la souris a été déplacé) et d'autres Les données (par exemple, la souris a été déplacée aux coordonnées 24, 12 ).

Maintenant, l'application doit traiter le message; Le système d'exploitation ou la boîte à outils de l'interface graphique est généralement sous la hotte, donc avec une magie noire que le message est envoyé à son destinataire et que le gestionnaire d'événements correct est exécuté. Lorsque le gestionnaire d'événements revient, la fonction interne appelée le gestionnaire d'événements revient, ainsi celle qui l'appelait et ainsi de suite, jusqu'à ce que le contrôle revienne sur la boucle principale, cela rappellera maintenant la fonction de récupération de messages magique pour obtenir un autre message. Ce cycle continue jusqu'à ce que l'application se termine.

Maintenant, j'ai écrit tout cela pour vous faire comprendre pourquoi le sommeil est mauvais dans une application d'interface graphique entraînée par événement: Si vous remarquez, alors qu'un message est traité aucun autre message ne peut être traité , depuis la principale Le fil est occupé à exécuter votre gestionnaire d'événements, qui, après tout, est une fonction appelée par la boucle de message. Donc, si vous faites votre manutention d'événement, la boucle de messagerie peut également dormir, ce qui signifie que l'application entre-temps ne recevra pas et ne traitera aucun autre message, y compris ceux qui rendent votre fenêtre repeindre, de sorte que votre application sera donc votre application. accrocher "du point de vue de l'utilisateur.

Longue histoire courte: n'utilisez pas de sommeil à moins que vous ne dormiez à dormir pendant très courte période (peu de millisecondes au plus), sinon l'interface graphique deviendra insensible. Vous avez plusieurs options pour remplacer le Sleep s: vous pouvez utiliser une minuterie (QTIMER), mais il peut vous obliger à faire beaucoup de comptabilité entre un événement de minuterie et l'autre. Une alternative populaire consiste à démarrer un fil de travail séparé: il manipulerait simplement la communication UDP et, étant séparé du fil principal, cela ne causerait aucun problème si nécessaire. De toute évidence, vous devez veiller à protéger les données partagées entre les threads avec des mutiles et veillez à éviter les conditions de race et à tous les autres problèmes qui se produisent avec la multithreading.