>> However if you're working with a server (daemon), you really 
>> don't want it at all. Your connections will go away, but you 
>> don't want that to kill your app. So you have to ignore SIGPIPE.
>> 
> 
> Hmm. This makes sense, yes, and I see where you are coming from. I've never
> had to deal with a pipe in the context of a server app. But couldn't you
> deal with this by ignoring the signal (I mean there is a current solution to
> the problem).
> 
> I guess one would have to weigh the benefits of having this feature
> available in a future release of netbsd and getting OpenVPN to work with
> that future release (people will have to upgrade their os to get openvpn
> support!) against having all new versions of OpenVPN work against all
> existing versions of netbsd (assuming ofcourse this is the only issue in
> getting openvpn work on netbsd). I don't have enough exposure to openvpn to
> rightly make this judgement.

OpenVPN works fine on NetBSD. One new feature uses this change. And as it's 
a bit mask list of flags, running a new version on a kernel that does not 
support this would not stop it working. It would just cope badly in the 
event of the recipient going away. If the port-share option isn't used, this 
code path will not be seen.

I see no reason not to add support for MSG_NOSIGNAL. It improves 
compatibility rather than reduces it. I'll certainly be adding it in my 
local source trees :-)

-- 
Stephen