Je sais que les programmeurs ne sont souvent pas si faciles avec les threads et la programmation parallèle, donc c'est une question pour les experts en la matière en priorité.Pourquoi dup (2) écouter des sockets dans plusieurs serveurs à thread?
Il semble y avoir une bonne pratique relativement acceptée mais inconnue d'appeler dup (2) sur les sockets d'écoute pour les applications de serveur à thread. Je comprends le principe général de «ne rien partager» pour la tranquillité d'esprit en évitant les conditions de course.
Ma question est la suivante: si le noyau fait déjà une exclusion mutuelle sur accept (2) renvoie des valeurs, exactement pourquoi est-ce intéressant de duper (2) le socket d'écoute?
Dans le cas où c'est vraiment une amélioration, quand la socket doit-elle être dup (2): après bind (2) ou après listen (2)?
Impossible de trouver une mention de cette pratique dans une recherche rapide. Ça me semble plutôt inutile. 'dup' crée uniquement un nouveau handle entier et duplique quelques indicateurs de bit relativement insignifiants (ou un seul), la * description de fichier ouverte * qui est la plus grande partie des données de fichiers/socket reste partagée. –
Je suppose qu'il pourrait être lié à fermer (2) condition de course? – thodg
Normalement, un serveur ne ferme pas une prise d'écoute, mais si cela est nécessaire pour une raison quelconque, alors peut-être que cela pourrait être raisonnable. –