From owner-freebsd-arch Fri Jun 14 15:11:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 0E3E837B40E; Fri, 14 Jun 2002 15:11:35 -0700 (PDT) Received: from pool0043.cvx22-bradley.dialup.earthlink.net ([209.179.198.43] helo=mindspring.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17IzHu-00066Z-00; Fri, 14 Jun 2002 15:11:23 -0700 Message-ID: <3D0A69DE.F2214A69@mindspring.com> Date: Fri, 14 Jun 2002 15:10:38 -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: Giorgos Keramidas Cc: Mario Sergio Fujikawa Ferreira , Garance A Drosihn , FreeBSD-arch@FreeBSD.org, msmith@FreeBSD.org Subject: Re: Adding SO_NOSIGPIPE to -STABLE/-CURRENT References: <20020614022304.94570.qmail@exxodus.fedaykin.here> <20020614054920.1254.qmail@exxodus.fedaykin.here> <20020614133656.GB9021@hades.hell.gr> 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 Giorgos Keramidas wrote: > On 2002-06-14 02:48 -0300, Mario Sergio Fujikawa Ferreira wrote: > > Darwin call it SOF_NOSIGPIPE because they use it as socket > > flag as opposed to a socket option such as either SO_DONTTRUNC or > > SO_WANTMORE. > > > > Well, Linux has it as a socket option, it looks okay > > as a socket option so the name begins with SO_. SO_NOSIGPIPE > > because it describes well its use as it does in Darwin. > > > > However, that's my opinion. I am all open to suggestions. > > The example you mentioned above (threaded programs that want to > disable the signal for some of the threads, but not all of them) can > probably be implemented in userland with: [ ... ] Signal handling in threaded programs is a pain. Ideally, you would want signals to be queued (i.e. events, rather than persistent conditions), and you would want them to be delivered contextually, only to threads that are interested in them. 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. How will this option work with regards to individual threads? If an individual thread sets this option on an fd, does it set it on the fd for all threads, or only for the calling thread? 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? Frankly, the signal system is starting to feel like the threads used by the Lilliputions to tie down Gulliver so that he could not move. Adding more threads is probably not the right answer. If you are going to provide this facility, at *least* make it general, and not socket specific. Make it an fcntl, not a setsockopt. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message