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

dvyukov opened this issue Oct 7, 2014 · 1 comment

net: skip excessive read calls #8891

dvyukov opened this issue Oct 7, 2014 · 1 comment


Copy link

@dvyukov dvyukov 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

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:
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:
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
Copy link

@ALTree ALTree 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.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.