SIGPIPE,破管
我正在使用epoll在linux机器上的网络程序,我得到了来自gdb的错误消息。
I am working on a networking program using epoll on linux machine and I got the error message from gdb.
Program received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x7ffff609a700 (LWP 19788)]
0x00007ffff7bcdb2d in write () from /lib/libpthread.so.0
(gdb)
(gdb) backtrace
#0 0x00007ffff7bcdb2d in write () from /lib/libpthread.so.0
#1 0x0000000000416bc8 in WorkHandler::workLoop() ()
#2 0x0000000000416920 in WorkHandler::runWorkThread(void*) ()
#3 0x00007ffff7bc6971 in start_thread () from /lib/libpthread.so.0
#4 0x00007ffff718392d in clone () from /lib/libc.so.6
#5 0x0000000000000000 in ?? ()
我的服务器做n ^ 2次计算,我试图运行500个连接用户。什么原因可能导致此错误?如何解决这个问题?
My server doing n^2 time calculation and I tried to run the server with 500 connected users. What might cause this error? and how do I fix this?
while(1){
if(remainLength >= MAX_LENGTH)
currentSentLength = write(client->getFd(), sBuffer, MAX_LENGTH);
else
currentSentLength = write(client->getFd(), sBuffer, remainLength);
if(currentSentLength == -1){
log("WorkHandler::workLoop, connection has been lost \n");
break;
}
sBuffer += currentSentLength;
remainLength -= currentSentLength;
if(remainLength == 0)
break;
}
已经关闭(由远程端),您的程序将接收此信号。对于简单的命令行过滤程序,这通常是一个适当的默认操作,因为SIGPIPE的默认处理程序将终止程序。
When you write to a pipe that has been closed (by the remote end) , your program will receive this signal. For simple command-line filter programs, this is often an appropriate default action, since the default handler for SIGPIPE will terminate the program.
对于多线程程序,通常是忽略SIGPIPE信号,因此写入关闭的套接字不会终止程序。
For a multithreaded program, the correct action is usually to ignore the SIGPIPE signal, so that writing to a closed socket will not terminate the program.
请注意,您 在写入之前成功执行检查,因为远程端可能会在您的检查和对 write()
的调用之间关闭套接字。
Note that you cannot successfully perform a check before writing, since the remote end may close the socket in between your check and your call to write()
.
有关忽略SIGPIPE的更多信息,请参阅此问题:如何防止SIGPIPE(或正确处理它们)。
See this question for more information on ignoring SIGPIPE: How to prevent SIGPIPEs (or handle them properly).