Date: Mon, 17 Jun 2002 01:21:02 -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: <3D0D9BEE.BB8AE571@mindspring.com> References: <200206170747.g5H7l3uJ001188@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Michael Smith wrote: > > Shouldn't the framework install its own handler? > > How? Before the call, removing it after the call (worst case) or chaining it (best case). > Oh, please. There's no convention for vector chaining for signal > handlers; I cannot possibly imagine that you're so naive that you can't > immediately see where this scheme falls down. The use of the signals interface in the first place? 8-). Order of operation of setting of handlers becomes important; it's barely manageable to allow replacement of a handler by replacing a function called by the handler function, instead, and only ever installing -- never uninstalling -- the handler. Signals are not really appropriate for transparent use in libraries anyway. It's like making system calls directly via "syscall(2)" in threaded programs. I think that you have to be prepared to do a lot of work if you insist on using an interface in the wrong context. > > Basically, if I have an encapsulation framework, I pretty much > > expect it to encapsulate. > > This isn't an encapsulation anything. It's just a library. And you > clearly don't grasp the simple nature of either the problem or the > solution. The phrase "seperation of resource ownership" implied encapsulation for me; sorry for taking it that way, if that's not the way it was intended. > > 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? > > Have a library open a socket. Have the socket be closed by the remote > end without the application linked with the library not receive a > "surprise" SIGPIPE. > > That's it. The SIGPIPE should only occur in the case of a bogus "write", correct? In that case, the library should check the writability before attempting to write, shouldn't it? Or install a SIGPIPE handler around the call? Or just mask it completely, once, at library startup (.ctors), and document it as a side effect? I can see the rationale of wanting to save the two extra system calls in the case that the library attempts writes without really caring if the socket still exists at the time of the attempt. I guess I'm still wondering what library expects the OS to have this feature. It seems like it's a really new feature, and that sofware that really depends on it doesn't exist yet. What protocol is this for, since TCP returns ECONNRESET, not EPIPE, anyway? Thanks, -- 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?3D0D9BEE.BB8AE571>