Date: Mon, 17 Jun 2002 00:31:25 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Michael Smith <msmith@mass.dis.org> Cc: Giorgos Keramidas <keramida@ceid.upatras.gr>, Mario Sergio Fujikawa Ferreira <lioux@FreeBSD.org>, Garance A Drosihn <drosih@rpi.edu>, FreeBSD-arch@FreeBSD.org, msmith@FreeBSD.org Subject: Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT Message-ID: <3D0D904D.4752ADD4@mindspring.com> References: <200206142238.g5EMcQhv000828@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Michael Smith wrote: > > This SO_SIGPIPE discussion seems bent on trying to make the signal > > facility more able than it is, when in fact signals were (and are) > > a bad idea in the first place. > > Actually, this has nothing to do with it. > > The issue revolves around the seperation of resource ownership between a > program and the frameworks that it links with. In many cases, the > program has no idea that the framework has a pipe/socket open, and is > thus surprised by the signal. In other cases, it will install its own > handler and be confused. Shouldn't the framework install its own handler? And then, since the old handler is returned in the set call, it should daisy-chain call the signal handlers, until the default handler, and not call that one, if other handler are installed. Basically, if I have an encapsulation framework, I pretty much expect it to encapsulate. The problem with SIGPIPE is the same as the problem with SIGCHLD; it's not really a notification on a descriptor, and if you have a set of descriptors that might have it on them, then you have to poll them. This is one of the reasons it doesn't make sense. You'd have to be very careful to track which ones had it enabled and disabled, so that you only polled the ones with it enabled, when you saw it; even so, you'd have to poll them all, since, like SIGCHLD, getting the signal doesn't mean that there's only one even that caused the signal to be raised. The whole thing is really predicated on either the signals being queued for delivery (e.g. per POSIX RT signal queueing and Linux these days), or otherwise being able to treat signals as if they were real events, rather than just persistant conditions. If you don't assume queueing (FreeBSD doesn't support it, unless you capture the signals via kqueue()), then a signal isn't really an event, and there's really no correspondance with the fd for the socket for which the signal was raised in th first place. It's probably beeter to resolve whatever problem with something other than signals. > > Why are you getting SIGPIPE in the first place, rather than > > some other indicator? Isn't it because you are using the wrong > > system call to send data down a socket? > > No, it's because the socket's closed and the signal mask is process-wide. The only place I see this happening in the write path is in non-AF_INET sockets. It looks like the psignal(SIGPIPE) only ever happens if underlying code returns EPIPE, which none of the code in /sys/net or /sys/netinet does (there is one ECONNRESET in tcp_usrreq.c that is commented with an "/* XXX EPIPE> */"). I see the sosend case, but is the generic version of the routine used in any of the "struct pr_usrreqs" for anything other than real pipes (i.e. uipc_usrreqs declaration in uipc_usrreq.c)? > > If you are going to provide this facility, at *least* make it > > general, and not socket specific. Make it an fcntl, not a > > setsockopt. > > There aren't any file option bits left. > > And when was the last time you got SIGPIPE from a file being closed? Mostly, I get "EPIPE" being set in errno on write returning -1, and that's for command line things where I've actually used pipes when building the command. > Sorry Terry, this one's already been solved. The single issue here is > whether FreeBSD actually wants to take something back from Darwin, or > whether you're all just too stubborn and stuck up yourselves to take > what is, in reality, a trivial and entirely worthwhile change. I'm all for taking stuff back from Darwin; I'd desperately like FreeBSD to take Darwin's UDF implementation, for example, but the lack of block devices makes that one impossible. 8-(. > So much for "are Apple going to give anything back"? Try "is FreeBSD too > arrogant to accept anything from Apple"? I don't think this is representative of a declaration of war on "all things Apple". I guess I missed some of the side discussions you guys had at the recent Usenix conference. My base assumption, which could be wrong, is that no one would design new code to rely on signals if they didn't have to, so the reason for this was to support porting code from a system that supported the option to FreeBSD. My question was really pointed at "Is this the only way that supporting the porting of this code could be safely handled?". If this is just a feature to have because Linux has it, then it's a no-brainer (IMO) to say "no", unless someone is using it, then the answer should be "yes", for ABI compatability. If there's an application software reason to have it, though, then the answer *should* be "yes, for API compatability"... because it's exactly the same argument I've made in the past in favor of cloning devices being supported in FreeBSD, even if no one can come up with a problem that absolutely can't be solved without them. I guess I'm wondering what software FreeBSD will be able to run/problems will FreeBSD be able to solve, with this option present, that it couldn't without the option present? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D0D904D.4752ADD4>