Comment 1:

Will it increase latency?

Comment 2:

No. It should not:
1) cork(netfd)
2) write(netfd, "HTTP/1.1 200 OK... response headers ...\r\n\r\n")
3) sendfile(netfd, diskfd)
4) uncork(netfd)
Currently we don't do 1) and 4), which means 2) and 3) arrive in different packets.
This will halve the number of packets returned for small static files, but will also
help generally where Go's bufio.Writer(netfd) buffer size differs from the network MTU
size.
Of course, we'll measure this before submitting it and not submit it if it's worse.
(which would surprise me)

Comment 3 by pabuhr@google.com:

If corking is applied selectively, it should not introduce additional
latency.
There are cases where a header is followed immediately by data. Merging the
header with the
data by corking reduces or eliminates additional packets for small
messages, i,e, the header
and data are sent in a single packet rather than two.

Comment 4:

(from golang-dev)
I had been debating naming on a new method on (*net.TCPConn).SetNoPush vs SetCork, but
in light of,
http://dotat.at/writing/nopush.html
https://issues.apache.org/bugzilla/show_bug.cgi?id=53253 
I think SetCork is a better name & behavior.  It can return ErrNotImplemented or
something unless Linux or FreeBSD >= 4.5.

Comment 5:

It is a mistake to use names specific to some OS's features, like SetNoPush
or SetCork.
The name should be chosen for what it does. "Cork" is meaningless unless
you know the kernels.
What's really going on here is that the kernel is allowed to buffer writes
to the connection, and then you also need a way to flush them.
If we were going to add a new method, I would add something like
// SetBuffered controls whether writes to the connection can be buffered
// internally rather than sent immediately. Buffering is typically at the
// operating system level and may result in more efficient use of the
network.
//
// SetBuffered(true) enables buffering.
// SetBuffered(false) disables buffering and sends any buffered data.
SetBuffered(enabled bool) error

Comment 6:

Labels changed: added go1.3maybe.

Comment 7:

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

Comment 8:

Labels changed: added repo-main.

Nowadays the http server (both http1 and http2) do a fair bit of buffering themselves, so this is much less relevant than it was. The sendfile case is still problematic, but that's just 1 extra packet, and non-TLS is going out of vogue anyway.

I'm going to close this without doing anything.

If others want to prototype it and come back with performance numbers we can reopen this.