Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Jun 2002 15:10:38 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Giorgos Keramidas <keramida@ceid.upatras.gr>
Cc:        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:  <3D0A69DE.F2214A69@mindspring.com>
References:  <20020614022304.94570.qmail@exxodus.fedaykin.here> <p05111775b92f06977bcb@[128.113.24.47]> <20020614054920.1254.qmail@exxodus.fedaykin.here> <20020614133656.GB9021@hades.hell.gr>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D0A69DE.F2214A69>