Je dois envoyer et recevoir à plusieurs reprises des datagrammes UDP depuis/vers un socket. Mon idée était d'engendrer deux fils, l'un responsable de l'envoi et l'autre de la réception. L'idée entière n'a de sens que s'il est possible à un thread d'attendre recv() en bloquant et l'autre en cours d'exécution send() sur le même socket en même temps.Est-ce que deux threads peuvent être simultanément `send` et` recv` sur le même socket?
j'ai fait quelques recherches sur Google et a trouvé cette question SO: Are parallel calls to send/recv on the same socket valid? La réponse acceptée mentionne que send() et recv() sont thread-safe (ouf ...), mais procède à une remarque alarmante:
Cela ne signifient nécessairement qu'ils seront exécutés en parallèle
Oups. Cela signifie-t-il que si j'implémente mon idée multithread, vais-je finir par attendre que le thread expéditeur attende le recv() du thread de réception avant de commencer à envoyer ses données? Mal.
Il est douteux que cette réponse acceptée fait référence à deux s send() parallèles de » seulement, ou si la préoccupation est réelle aussi pour tenter de signer un send() en parallèle et un recv(). Par conséquent:
Est-ce un appel à send() et un appel à recv() sur la même prise par deux fils être exécuté en parallèle, ou sera l'un de ces appels bloquer jusqu'à ce que les autres déclarations?
Pourquoi ne pas configurer une file d'attente de travail pour les paquets reçus qui sont traités par l'autre thread? Le partage de descripteurs de fichiers entre les threads est probablement une mauvaise idée. – tadman
1. Ils peuvent ... acheter, à mon humble avis: 2. Ce serait une mauvaise conception de le faire. 3. En supposant qu'un seul thread est en train de lire et que l'autre ne fait que l'envoyer, il peut s'agir d'un design légèrement meilleur, mais il est encore pauvre. 4. Le blocage sur 'send' ou' recv' n'est pas une utilisation efficace de la CPU ou de l'heure de votre programme. 4. Vous avez à peine besoin de threads pour cela, vous pouvez exécuter un serveur entier avec plus de 10K sockets sur un thread. – Myst
@tadman Pourquoi est-ce une mauvaise idée? Le problème est que les paquets doivent être envoyés toutes les 20ms, donc je ne peux pas attendre de recevoir quelque chose avant d'envoyer quoi que ce soit. Je pensais que la désignation d'un thread pour effectuer l'envoi rendrait plus facile de garder cet intervalle de 20 ms non affecté par un surdébit de traitement non lié – gaazkam