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
