Is there any reason that send(), when the peer has closed the socket, should
cause the process to exit?
In particular, when send() is called, the subsequent MsgSend() never
returns; instead the process exits.
We ran it with the instrumented kernel and saw the KER_EXIT:MSG_SENDV/11
with status -1, followed by KER_CALL:THREAD_DESTROYALL/48.
Can anyone think of an explanation, or something that we could try to help
troubleshoot further?
Thanks,
lew
Lewis Donzis <lew@perftech.com> wrote:
Is there any reason that send(), when the peer has closed the socket, should
cause the process to exit?
Yes. SIGPIPE. This is normal.
In particular, when send() is called, the subsequent MsgSend() never
returns; instead the process exits.We ran it with the instrumented kernel and saw the KER_EXIT:MSG_SENDV/11
with status -1, followed by KER_CALL:THREAD_DESTROYALL/48.Can anyone think of an explanation, or something that we could try to help
troubleshoot further?
SIGPIPE.
write()/send() to a socket where the other side has closed will drop
a SIGPIPE on the sending/writing process. (Default, you die.) If
you handle/ignore SIGPIPE, the write()/send() will return -1, errno
set to EPIPE.
This is normal expected behaviour for pipes and anything that inherits
behaviour from pipes, explicitly including TCP sockets.
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:avv7hm$f6$1@nntp.qnx.com…
write()/send() to a socket where the other side has closed will drop
a SIGPIPE on the sending/writing process. (Default, you die.) If
you handle/ignore SIGPIPE, the write()/send() will return -1, errno
set to EPIPE.
That’s very helpful, thanks!
This is normal expected behaviour for pipes and anything that inherits
behaviour from pipes, explicitly including TCP sockets.
Really? Meaning normal UNIX/POSIX behavior or normal QNX behavior? We’ve
never encountered anything like that on other systems.
Thanks for your help.
lew
Lewis Donzis <lew@perftech.com> wrote:
“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:avv7hm$f6$> 1@nntp.qnx.com> …
write()/send() to a socket where the other side has closed will drop
a SIGPIPE on the sending/writing process. (Default, you die.) If
you handle/ignore SIGPIPE, the write()/send() will return -1, errno
set to EPIPE.That’s very helpful, thanks!
This is normal expected behaviour for pipes and anything that inherits
behaviour from pipes, explicitly including TCP sockets.Really? Meaning normal UNIX/POSIX behavior or normal QNX behavior? We’ve
never encountered anything like that on other systems.
Absolutely rock-solid normal Unix behaviour. For instance, page
264 of Advanced Programming in the Unix Environment (by W. Richard
Stevens, an excellent book on Unix programming) says, “SIGPIPE, (generated
when a process writes to a pipe after the reader has terminated”.
The POSIX spec for send(), in talking about errno of EPIPE, says,
“In the latter case, and if the socket is of type SOCK_STREAM, the
SIGPIPE signal is gneerated to the calling thread.”
This is normal Unix/POSIX behaviour.
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
David Gibbs wrote:
This is normal Unix/POSIX behaviour.
Thanks very much. I’m sorry to have asked 'cause it seems so obvious!
Thanks again for the quick answer.
lew