Subject: Re: OpenVPN
To: None <email@example.com>
From: Stephen Borrill <firstname.lastname@example.org>
Date: 05/12/2006 11:08:02
>> 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 :-)