Re: SIGPIPE => SIG_IGN : EPIPE returned always to the thread raising SIGPIPE?

On Sun, 31 Dec 2006 13:12:06 +0100 Oliver Kowalke <oliver.kowalke@xxxxxx> wrote:
Hello,
I've following question:

In a multithreaded library a thread sets the sigaction SIG_IGN for signal
SIGPIPE if it tries to write to a socket and resets to the old sigaction
with SIG_DFL afterwards.

Will EPIPE allways be returned to the same thread if the socket was closed
before write (and RST was received)?

Well yes, since EPIPE is not a signal, it is the errno setting after
write() returns -1. It is simply not possible for another thread to
get errno set to EPIPE for your thread's write().

If yes is this guaranteed?

Yes.

But changing the signal action to SIG_IGN probably isn't the correct
way to handle this. The application might be catching SIGPIPE (or,
depending on the default behavior) and if you change the handler you
are changing it for the process. For a single-threaded process your
approach sounds reasonable, but not for a multi-threaded process.

The best approach is to document the need to handle or ignore SIGPIPE.

-frank
.

Relevant Pages