Erreur de tuyau cassé

J'utilise write() sur un socket de données ouvert dans l'implémentation FTP pour envoyer le fichier. Mais après avoir écrit quelques données, il est suspendu pendant un certain temps; et après cela, il revient avec une erreur de tuyau cassé. toute aide dans ce domaine sera grandement appréciée. Mon processus lit les paquets d'un buff et écrit dans le socket. J'ai remarqué ce problème avec une bande passante accrue. Si j'ai augmenté le nombre de paquets à traiter, le problème arrive. J'utilise FreeBSD.Erreur de tuyau cassé

J'utilise deux threads on lit les paquets et écrit dans un buffer ... le second thread lit ces paquets à partir de buffer et écrit dans socket.

Merci pour votre aide Alexander

Source

2010-08-12 alexander

Vous n'avez pas fourni suffisamment d'informations pour diagnostiquer le problème. Un bon point de départ est un morceau de code minimum compilable qui démontre le problème. –

J'utilise deux threads on lit les paquets et écrit dans un buffer ... le second thread lit ces paquets à partir du buffer et les écrit dans socket. – alexander

Je dois me demander pourquoi vous utilisez des threads? Habituellement, les programmes ne font que lire et écrire, en utilisant des E/S non bloquantes et en interrogeant ou en sélectionnant. Les threads * fonctionneront * mais présenteront autant de chances pour les courses et les bugs étranges ... –

EPIPE peuvent être définies comme un code d'erreur, et/ou SIGPIPE élevés (selon des drapeaux), lorsque vous essayez d'écrire dans un descripteur de fichier qui a fermé. Il est probable que l'extrémité distante de votre connexion est fermée et que vous n'avez pas vérifié l'événement close/EOF (généralement renvoyé via l'événement read lorsque poll/select ou la valeur de retour read/recv).

Source

2010-08-12 16:00:02

SIGPIPE est envoyé à votre processus par le noyau lorsque vous tentez d'écrire des données dans un tube rompu. Cela peut arriver, par exemple, si le côté réception a fermé le socket pendant que vous écrivez, ou si le socket est accidentellement fermé à partir d'un autre thread, etc. Il y a beaucoup de raisons possibles à cela. La plupart des applications ont tendance à ignorer ce signal et à gérer les erreurs en se basant sur le code de retour "write" car il n'y a rien de raisonnable à faire dans le gestionnaire de traitement du signal SIGPIPE. Fondamentalement, réglez le gestionnaire SIGPIPE sur SIG_IGN afin de l'ignorer et regardez une liste de codes de retour possibles à partir de l'appel système "write" et gérez-les en conséquence.

Source

2010-08-12 16:06:19

Répondre

Questions connexes