From owner-freebsd-arch Mon Jun 17 1:21:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 5688137B40C; Mon, 17 Jun 2002 01:21:46 -0700 (PDT) Received: from pool0032.cvx21-bradley.dialup.earthlink.net ([209.179.192.32] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17Jrld-0004He-00; Mon, 17 Jun 2002 01:21:41 -0700 Message-ID: <3D0D9BEE.BB8AE571@mindspring.com> Date: Mon, 17 Jun 2002 01:21:02 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Smith Cc: Giorgos Keramidas , Mario Sergio Fujikawa Ferreira , Garance A Drosihn , FreeBSD-arch@freebsd.org, msmith@freebsd.org Subject: Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT References: <200206170747.g5H7l3uJ001188@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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