Date: Mon, 17 Jun 2002 00:47:03 -0700 From: Michael Smith <msmith@mass.dis.org> To: Terry Lambert <tlambert2@mindspring.com> 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: <200206170747.g5H7l3uJ001188@mass.dis.org> In-Reply-To: Your message of "Mon, 17 Jun 2002 00:31:25 PDT." <3D0D904D.4752ADD4@mindspring.com>
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? How? > 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. 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. > 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. > 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-(. That has entirely nothing do with it. > 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. = Mike -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt 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?200206170747.g5H7l3uJ001188>