Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: skip excessive read calls #8891

Closed
dvyukov opened this issue Oct 7, 2014 · 1 comment

Comments

Projects
None yet
4 participants
@dvyukov
Copy link
Member

commented Oct 7, 2014

Currently we always call syscall.Read before blocking on epoll in net.Conn.Read. This is
not necessary for connection-oriented sockets. According to man 7 epoll:

"For stream-oriented files (e.g., pipe, FIFO, stream socket), the condition that
the read/write I/O space is exhausted can also be detected by checking the amount of
data read from / written to the target file descriptor. For example, if you call read(2)
by asking to read a certain amount of data and read(2) returns a lower number of bytes,
you can be sure of having exhausted the read I/O space for the file descriptor. The same
is true when writing using write(2). (Avoid this latter technique if you cannot
guarantee that the monitored file descriptor always refers to a stream-oriented
file.)"

So if a previous Read has exhausted IO space, the chances are it's still exhausted, and
we can skip syscall.Read and wait on epoll. If new data has arrived since last Read,
waitRead will just instantly return, so we don't lose anything.

The change is actually quite trivial:
https://golang.org/cl/154040043/diff/40001/src/net/fd_unix.go
But the last time I tested it, Reads were hanging episodically with this change.
It can be due to a bug in the CL.
Or due to: https://golang.org/issue/6336
Or due to a kernel bug.
The change needs to be retested.
Most likely we also need to disable the optimization on level-triggered solaris. Afact,
kqueue should be fine, but that needs to be tested as well.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed release-none labels Apr 10, 2015

@ALTree

This comment has been minimized.

Copy link
Member

commented Feb 2, 2017

Closing in favour of #15735 (net: add mechanism to wait for readability on a TCPConn), which has a milestone and discussion and people in it.

@ALTree ALTree closed this Feb 2, 2017

@golang golang locked and limited conversation to collaborators Feb 2, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.