communication de port série à threads en C++ avec Qt

Question

J'écris une application de bureau QT qui va afficher des informations reçues à partir d'un port série. Par conséquent, une classe a été créée et compressée dans une DLL à l'aide des fonctionnalités standard de l'API Windows pour communiquer avec le périphérique connecté (CreateFile, ReadFile, WriteFile, ...). Au moment où un temporisateur appelle la DLL à un débit prédéfini [< 200ms], l'interface se bloque pendant de courtes périodes. Pour cette raison, je pense à utiliser un thread pour faire le port série, cela va aussi tout afficher.

Est-il préférable d'utiliser des threads pour ce problème ou devrais-je réécrire la classe pour faire l'événement de travail basé? La cible est, que le gui ne gèle pas. J'ai résolu le problème en utilisant une classe de travail dérivée QThread avec une fonction run() ombragée, qui gère la communication du port série en arrière-plan et met à jour le GUI lorsque de nouvelles informations sont disponibles.

Answer 1

Dans de nombreux cas d'utilisation, il est recommandé d'effectuer toutes les E/S (synchrones) de blocage sur un thread distinct, en particulier lorsqu'une interface utilisateur graphique est impliquée. Here's a page I've referenced en ce qui concerne les défis avec les E/S synchrones (par opposition à asynchrone où votre code ne bloque pas, mais est toujours mono-thread, ou parallèle que vous discutez). Il y a plus de problèmes que simplement ce que vous avez soulevé, par exemple:

• Et s'il n'y a pas de données disponibles? L'interface graphique bloque-t-elle jusqu'à ce qu'il y ait des données? Par exemple, si l'expéditeur était éteint, il n'y aurait pas de données
• Que fait le programme si le périphérique d'E/S n'est plus disponible? Par exemple, s'il s'agit d'un adaptateur USB-série, que se passe-t-il si l'adaptateur est débranché?