Problème lors de la fermeture des sockets

J'essaye d'écrire un programme client/serveur avec des threads. Je ferme la prise une fois la connexion terminée. Les serveurs obtiennent beaucoup de nouvelles connexions, et le numéro de socket (descripteur de fichier) augmente très rapidement: après 5 minutes de fonctionnement j'étais déjà au niveau du descripteur de fichier 800!Problème lors de la fermeture des sockets

Est-ce normal? Les threads partagent-ils des descripteurs de fichiers? Quand est-ce que close(sockfd); est le numéro diffusé immédiatement ou après un certain temps? PS: J'avais l'habitude de faire avec fork(), et je n'ai pas eu ce problème. Merci

Source

2010-03-17 Zenet

est-ce que cela pose vraiment un problème? Est-ce que votre code ne fonctionne pas? pourquoi vous souciez-vous d'un numéro dont la mise en œuvre est définie? que feriez-vous si votre système assignait aléatoirement des descripteurs de fichiers et vous donnait 123456789 en tant que descripteur de fichier? –

@Adrien Plisson Parce que les filedescripteurs sont assurés d'utiliser le plus petit nombre disponible. Cela signifie que s'il obtient de nouveaux fds avec la valeur 800, il a 800 fds ouverts, ce qui indique probablement une fuite de ressources - ce qui est mauvais. le numéro fd est également mappé directement aux ensembles de bits, par ex. un ensemble select(), et ce nombre de bits sont finis - donc la valeur réelle est importante. – nos

Quel système d'exploitation? Si vous êtes sur Linux, vous pouvez voir ce que ces descripteurs de fichiers appellent tous en regardant dans/proc//fd/' – caf

fichier

descripteurs un re partagé entre tous les threads, donc le fermer dans un thread le ferme pour tous les autres threads. close() libère le fd lors du retour d'appel (sauf si une erreur se produit)

Note qui peut fermer retourner une erreur si:

Ne pas vérifier la valeur de retour de près est une erreur de programmation courante mais grave . Il est tout à fait possible que les erreurs sur une opération d'écriture précédente (2) soient d'abord signalées à la fermeture finale. Ne pas vérifier la valeur de retour lors de la fermeture du fichier peut entraîner une perte de données silencieuse. Cela peut notamment être observé avec NFS et les quotas de disque.

Vérifiez l'utilisation d'autres descripteurs de fichier que vos supports, peut-être que vous avez des fuites ailleurs - p. si vous ouvrez des fichiers normaux

Source

2010-03-17 10:07:41 nos

De pthreads(7):

POSIX.1 exige également que les threads partagent une série d'autres attributs (c.-à-ces attributs sont par processus plutôt que par thread):

descripteurs de fichiers ouverts

Source

2010-03-17 09:49:28 wRAR

Problème lors de la fermeture des sockets

Répondre

Questions connexes