What’s is the value of n returned on windows?

@davecheney

the return n is 3

what is the value of n on the linux system?

@davecheney on linux,when call closeread,the read will return with an error

Read returns two values, a count of the number of bytes and an error. You’ve identified that the error is not nil, what was the count of the number of bytes read?

@davecheney the count of the number is 0，the client is sleep on time.Sleep(time.Miunte) the client didn't send any thing

Thank you for explaining. I’m trying to understand the Issue you are reporting. It is not that the code panics under linux and not under windows because the panic is in your code, not go.

The difference appears to be that under linux when you call CloseRead in another goroutine the Goroutine waiting in Read receives 3, nil on windows and 0, (some non nil error) on linux. Is that a correct summary?

@davecheney the summary is:

when a connect is block on Read()

on linux:net.TCPConn.CloseRead() will cause the block Read() return with 0 and error
on window:net.TCPConn.CloseRead() will not cause the block Read() return,the connect is still block on Read(),when a client send a message after server CloseRead(),the server still can read the message.

run the code by your self or show it to other developers,they will know what happened

I’m sorry I don’t have access to a windows computer.

@chenjie199234 can you please try this self contained program

(~/src) % go run test.go
close read success
0, [], EOF
(~/src) % cat test.go
package main

import (
        "fmt"
        "log"
        "net"
        "time"
)

func main() {
        addr, err := net.ResolveTCPAddr("tcp", "127.0.0.1:9234")
        check(err)
        l, err := net.ListenTCP("tcp", addr)
        check(err)
        go func() {
                c, err := net.DialTCP("tcp", nil, addr)
                check(err)
                time.Sleep(time.Minute)
                c.Write([]byte("123"))
        }()
        c, err := l.AcceptTCP()
        check(err)
        go func() {
                time.Sleep(time.Second)
                c.CloseRead()
                println("close read success")
        }()
        buf := make([]byte, 1024)
        n, err := c.Read(buf)
        buf = buf[:n]
        fmt.Printf("%v, %v, %v\n", n, buf, err)
}

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

@davecheney on windows return this:between the first line output and second line output,the program will block 1 minute

@chenjie199234 thank you for confirming. I'm going to hand this over to the windows experts now. /cc @alexbrainman

Thank you @davecheney for helping here. I can reproduce @chenjie199234 result on Windows, but I am not convinced there is a problem here.

We do

client Read
client CloseRead
server Write

in that order.

It appears that CloseRead behaves differently on Linux and Windows.

On Linux it makes Read return EOF, and (I assume) makes Write fail.

On Windows it makes Read return sent bytes, and (I assume) makes Write succeed.

I say either scenario is fine. There is a race here between Read and CloseRead, and result here depends on network stack implementation.

In my view, CloseRead cannot be used for anything useful. Only Close and CloseWrite are useful. Both ends of the connection should keep reading from the connection until EOF, if you do not want to loose some data.

Alex

cc @ianlancetaylor @bcmills