net: enable socket creation w/ close-on-exec on freebsd

[mikioh]

Linux has already introduced this feature in Go 1.2. So it would nice to live with
quickly and safely not dealing with socket descriptor race conditions in use of
fork+exec+multiple threads (even though current os+syscall ensure not to happen such
blunders).

Note:
- Both FreeBSD 10 and Solaris support SOCK_CLOEXEC, SOCK_NONBLOCK and syscall ACCEPT4
- NetBSD 6.0 supports SOCK_CLOEXEC, SOCK_NONBLOCK and syscall PACCEPT

[mikioh]

Comment 1:

Labels changed: added release-go1.3maybe, removed release-go1.3.

[ianlancetaylor]

Comment 2:

For the record, this is easy enough for people with access to those systems for testing.
1) Make sure the syscall package defines SOCK_CLOEXEC and Accept4.
2) Change the build constraints so that net/sock_cloexec.go is built instead of
net/sys_cloexec.go.

[mikioh]

Comment 3:

Sure, thanks.
--- a/src/pkg/net/sock_bsd.go
+++ b/src/pkg/net/sock_bsd.go
+func probeSocketLayer() bool {
+   switch runtime.GOOS {
+   case "freebsd":
+       // The SOCK_NONBLOCK and SOCK_CLOEXEC flags were introduced in
+       // FreeBSD 10.
+       if osrel, err := syscall.SysctlUint32("kern.osreldate"); err == nil {
+           // See http://www.freebsd.org/doc/en/books/porters-handbook/freebsd-versions.html.
+           if osrel >= 1000000 {
+               return true
+           }
+       }
+       return false
+   default:
+       return false
+   }
+}

[mikioh]

Comment 4:

> 2) Change the build constraints
It works to see the gap btw platforms but doesn't work for the gap btw kernel versions.

[mikioh]

Comment 5:

Sounds the retreat... this issue just focuses on FreeBSD.

[mikioh]

Comment 6:

This issue was updated by revision d9fc789.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/70490043

[mikioh]

Comment 7:

This issue was updated by revision a918c2c.

Update issue #7428
LGTM=r, bradfitz
R=golang-codereviews, rsc, minux.ma, r, bradfitz
CC=golang-codereviews
https://golang.org/cl/68880043

[mikioh]

Comment 8:

This issue was closed by revision 1d086e3.

Status changed to Fixed.