Sélectionnez() appel système dans les discussions?

Question

Je lis les données de plusieurs ports série. Actuellement, j'utilise un gestionnaire de signal personnalisé (en définissant sa_handler) pour comparer et réactiver les threads en fonction des informations du descripteur de fichier. Je cherchais un moyen d'avoir des threads individuels avec des gestionnaires de signaux uniques, à cet égard, j'ai trouvé que l'appel système choisi doit être utilisé.

Maintenant, j'ai des questions suivantes:

1. Si j'utilise un fil (Qt) alors où dois-je mettre l'appel système de sélection pour surveiller le port série?
2. L'appel système select est-il sûr?
3. Est-ce que le processeur est important parce qu'il y a beaucoup de choses qui se passent dans mon application, y compris la mise à jour de l'interface graphique?

S'il vous plaît ne me dérange pas, si vous trouvez ces questions ridicules. Je n'ai jamais utilisé un tel mécanisme pour la communication série.

Answer 1

Le POSIX specification (select) est l'emplacement à rechercher pour la définition select. Personnellement, je recommande poll - il a une meilleure interface et peut gérer n'importe quel nombre de descripteurs, plutôt qu'une limite définie par le système.

Si je comprends bien, vous éveillez des threads basés sur l'état de certains descripteurs. Une meilleure façon serait de faire en sorte que chaque thread ait son propre descripteur et l'appel lui-même. Vous voyez, select ne modifie pas l'état du système, et tant que vous utilisez des variables locales thread, il sera sûr. Cependant, vous voudrez certainement vous assurer de ne pas fermer un descripteur dont dépend un thread. L'utilisation de select/poll avec un timeout laisse l '"attente" du côté du noyau, ce qui signifie que le thread est généralement mis en veille. Pendant que le thread est en veille, il n'utilise pas de temps CPU. A tout/en boucle sur un appel select sans délai d'attente d'autre part vous donnera une utilisation du processeur plus que vous tourner constamment dans la boucle.

Espérons que cela aide.

EDIT: En outre, select/poll peut avoir des résultats imprévisibles lorsque vous travaillez avec le descripteur même dans plusieurs threads.La raison la plus simple est que le premier thread peut être réveillé car le descripteur est prêt à être lu, mais le second thread doit attendre le next "disponible pour la lecture" wakeup.

Tant que vous n'êtes pas select sur le même descripteur dans plusieurs threads, vous ne devriez pas avoir de problème.

Answer 2

C'est un appel système - il devrait être thread safe, je pense.

Je ne l'ai pas fait avant, mais je serais plutôt surpris, si ce n'est pas le cas. L'importance de l'UC select() dépend largement du nombre de handles de fichiers que vous attendez. select() est principalement utilisé, pour attendre qu'un nombre (> 1) de handles de fichiers soit prêt.

Il convient également de mentionner que select() ne doit pas être utilisé pour interroger le fichier poignées - pour des raisons de performance. L'utilisation normale est: Vous avez terminé votre travail et il peut s'écouler du temps jusqu'à ce que la prochaine chose se passe. Maintenant vous suspendez votre processus avec select et laissez un autre processus s'exécuter. select() suspend normalement le processus actif. Comment cela fonctionne avec les discussions, je ne suis pas sûr! Je pense que tout le processus (et tous les threads) sont suspendus. Mais cela pourrait être documenté. Cela dépend aussi (sous Linux) si vous utilisez des threads système ou des User-Threads. Le noyau ne connaîtra pas User-Threads et donc suspendra tout le processus.