Re: Adding an option to avoid SIGPIPE for all file descriptors

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> Hello,
> 
> In most programs the delivery of SIGPIPE (typically when one side
> of a socket or pipe closes and the other side tries to write) is
> annoying to handle, and the only solution to avoid it is to have
> the main program do signal(SIGPIPE, SIG_IGN), so the the system
> calls set errno = EPIPE instead. It would be nice if the default
> was the other way around (you needed to ask for SIGPIPE to get it,
> the same way you ask for SIGIO), but it is too late to do this now.
> 
> If you are a library writer who is dealing with pipes or sockets
> you are at the mercy of the main program as to how this is going
> to be handled. If you are a threaded program, the situation is even
> more complicated. Setting the signal handler is an all or nothing
> solution and other OS's have come up with many solutions for this.
> 
> Namely setsockopt SO_NOSIGPIPE (FreeBSD/MacOSX),
> fcntl(F_SETNOSIGPIPE/F_GETNOSIGPIPE) (MacOSX).  This has led to
> even more complexity (what happens if the socket is closed on
> SO_NOSIGPIPE? SO_NP_EXTENSIONS? ugh!). What I propose to do, and
> the patch here implements it, is to handle the EPIPE disposition
> at the file flags (regardless if the file descriptor is a socket or
> not) and send SIGPIPE only if the flag O_NOSIGPIPE is clear. This
> is actually simpler and less intrusive to implement (because it
> does not special-case sockets, and the signal delivery is still
> centralized for all file descriptors), plus it handles all current
> and future file descriptor types or drivers that can return EPIPE.
> 
> Comments?

heh, each BSDs do their own...

please don't forget compat_netbsd32 copy.

btw, shouldn't SIGPIPE be sent to the calling thread, not the process?

YAMAMOTO Takashi