管道破裂错误
我在 FTP 实现中的打开的数据套接字上使用 write() 来发送文件。但写入一些数据后，它会挂起一段时间；之后它会返回“损坏的管道”错误。对此的任何帮助将不胜感激。我的进程从一个缓冲区读取数据包并写入套接字。我在增加带宽时注意到了这个问题。如果我增加了要处理的数据包数量，那么问题就来了。我正在使用 FreeBSD。
我正在使用两个线程，一个线程读取数据包并将其写入缓冲区...第二个线程从缓冲区读取这些数据包并写入套接字。
感谢您的帮助 亚历山大
I am using write() on a opened data socket in FTP implementation to send the file out. But after writing some data it is hanging for some time; and after that it is returning with Broken pipe error. any help in this will greatly appreciated. My process reads packets from one buff and writes in to the socket. I noticed this problem with increased bandwidth. If i increased number of packets to be processed then the problem is coming. i am using FreeBSD.
I am using two threads one reads packets and writes in to a buffer ... second thread reads these packets from buffer and writes in to socket.
Thanks For your help
Alexander
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当检测到尝试将数据写入损坏的管道时，SIGPIPE 会由内核发送到您的进程。例如，如果接收方在写入时关闭了套接字，或者套接字被另一个线程意外关闭等，则可能会发生这种情况。造成这种情况的原因有很多。大多数应用程序倾向于忽略此信号并根据“write”处理错误返回代码，因为在 SIGPIPE 信号处理处理程序中您无法执行任何合理的操作。基本上，将 SIGPIPE 处理程序设置为 SIG_IGN 以便忽略它并查看可能的返回代码列表来自“write”系统调用并相应地处理它们。
SIGPIPE is sent to your process by the kernel when attempt to write data to a broken pipe is detected. This might happen, for example, if receiving side has closed the socket while you writing, or if socket is accidentally closed from another thread, etc. There are a lot of possible reasons for that. Most applications tend to ignore this signal and handle errors basing on "write" return code because there is nothing reasonable you can do in SIGPIPE signal processing handler. Basically, set SIGPIPE handler to SIG_IGN in order to ignore it and look at a list of possible return codes from "write" system call and handle them accordingly.
当您尝试写入已关闭的文件描述符时，
EPIPE可能会设置为错误代码，和/或引发SIGPIPE（取决于标志）。连接的远程端点可能已关闭，并且您尚未检查 close/EOF 事件（通常在poll/select时通过读取事件返回ing，或从read/recv返回零值）。EPIPEmay be set as an error code, and/orSIGPIPEraised (depending on flags), when you attempt to write to a file descriptor that has closed. It is likely that the remote endpoint of your connection has closed, and you've not checked for the close/EOF event (typically returned via the read event whenpoll/selecting, or a return value of zero fromread/recv).