Loco
07-24-2002, 10:17 PM
Taken from the original FAQ.
2.19 - I see that send()/write() can generate SIGPIPE. Is there any advantage to handling the signal, rather than just ignoring it and checking for the EPIPE error?
From Andrew Gierth (andrew@erlenstar.demon.co.uk):
In general, the only parameter passed to a signal handler is the signal number that caused it to be invoked. Some systems have optional additional parameters, but they are no use to you in this case.
My advice is to just ignore SIGPIPE as you suggest. That's what I do in just about all of my socket code; errno values are easier to handle than signals (in fact, the first revision of the FAQ failed to mention SIGPIPE in that context; I'd got so used to ignoring it...)
There is one situation where you should not ignore SIGPIPE; if you are going to exec() another program with stdout redirected to a socket. In this case it is probably wise to set SIGPIPE to SIG_DFL before doing the exec().
Jesse Norell has pointed out that if you are using SO_KEEPALIVE to test the connection, and you aren't doing reads or writes very frequently, you might want to leave SIGPIPE enabled so that your server process gets signalled when the system determines your link is dead. Normally though you will just check returns from read()/write() and act appropriately.
From: Corey
And once you receive an EPIPE error on the client are you forced to close that connection and reestablish a new connection? Even though the server thinks there is still a connection?
From: Zoran
What shall I do when writing a library for example. When I write my library in a way that the user simply calls some functions but doesn't have to care whether there is something going on over a networking interface or any other interface. When a socket is opened inside the library I don't find it a good idea to catch and ignore SIGPIPE from inside the library, on the other hand the
user of the library shouldn't have to care about internals of the library. Now the idea is to catch the signal and test whether it was generated due to a operation on the socket created by the library, if not, pass it to an other signal handler or the default action. Would it be possible to do so?
2.19 - I see that send()/write() can generate SIGPIPE. Is there any advantage to handling the signal, rather than just ignoring it and checking for the EPIPE error?
From Andrew Gierth (andrew@erlenstar.demon.co.uk):
In general, the only parameter passed to a signal handler is the signal number that caused it to be invoked. Some systems have optional additional parameters, but they are no use to you in this case.
My advice is to just ignore SIGPIPE as you suggest. That's what I do in just about all of my socket code; errno values are easier to handle than signals (in fact, the first revision of the FAQ failed to mention SIGPIPE in that context; I'd got so used to ignoring it...)
There is one situation where you should not ignore SIGPIPE; if you are going to exec() another program with stdout redirected to a socket. In this case it is probably wise to set SIGPIPE to SIG_DFL before doing the exec().
Jesse Norell has pointed out that if you are using SO_KEEPALIVE to test the connection, and you aren't doing reads or writes very frequently, you might want to leave SIGPIPE enabled so that your server process gets signalled when the system determines your link is dead. Normally though you will just check returns from read()/write() and act appropriately.
From: Corey
And once you receive an EPIPE error on the client are you forced to close that connection and reestablish a new connection? Even though the server thinks there is still a connection?
From: Zoran
What shall I do when writing a library for example. When I write my library in a way that the user simply calls some functions but doesn't have to care whether there is something going on over a networking interface or any other interface. When a socket is opened inside the library I don't find it a good idea to catch and ignore SIGPIPE from inside the library, on the other hand the
user of the library shouldn't have to care about internals of the library. Now the idea is to catch the signal and test whether it was generated due to a operation on the socket created by the library, if not, pass it to an other signal handler or the default action. Would it be possible to do so?