Go软件包syscall conn.Read（）是非阻塞的，并导致较高的CPU使用率

Question

Strangely, in my case Read() is non-blocking and caused high CPU usage.

My code:

In function main:

l, err := net.Listen("tcp", ":13798")


if err != nil {
    log.Fatal(err)
  }

  for {
    // Wait for a connection.
    conn, err := l.Accept()
    if err != nil {
      log.Fatal(err)
    }
    // Handle the connection in a new goroutine.
    // The loop then returns to accepting, so that
    // multiple connections may be served concurrently.
    go reqHandler.TCPHandler(conn)

    runtime.Gosched()
  }

Function TCPHandler:

func TCPHandler(conn net.Conn) {
request := make([]byte, 4096)
  for {
    read_len, err := conn.Read(request)

    if err != nil {
        if err.Error() == "use of closed network connection" {
        LOG("Conn closed, error might happened")
        break
      }

      neterr, ok := err.(net.Error);
      if ok && neterr.Timeout() {
        fmt.Println(neterr)
        LOG("Client timeout!")
        break
      }
    }

    if read_len == 0 {
     LOG("Nothing read")
      continue
    } else {
      // do something
    }
    request := make([]byte, 4096)
  }
}

The problem is, conn.Read() is non-blocking, so every time it goes to LOG("Nothing read") then continue, this is causing high CPU usage. How to make conn.Read() a block call?

I've researched into syscall package but got stucked at Syscall.Read() Since I found this issue on my OS X 10.8.3 here is the source code related:

http://golang.org/src/pkg/syscall/zsyscall_darwin_amd64.go?h=Read#L898

I have no idea what Syscall(SYS_READ, uintptr(fd), uintptr(_p0), uintptr(len(p))) means.

Answer 1

You're not handling TCP correctly. When conn.Read() returns 0 bytes read, that means the peer has closed the TCP connection gracefully. You should probably close your end of the TCP connection in this case.

(Note that this is not special to Go, read()/recv() returning 0 on a TCP connection more or less universally means the other end has closed the connection)