Closed
Description
by sebastien.paolacci:
What steps will reproduce the problem?
1. Set a small, but large enough for sending few bytes, write timeout.
2. Send a large buffer that can't be sent in one single pass.
3. Make client's receive loop fast enough to respect timeout, but not to respect (number
of chunks x timeout).
What is the expected output?
Full buffer sent, no timeout.
What do you see instead?
Timeout.
Which compiler are you using (5g, 6g, 8g, gccgo)?
6g
Which operating system are you using?
linux/amd64
Which revision are you using? (hg identify)
r60.3,tip
Please provide any additional information below.
Current Write implementation handles partial writes, which make it really suitable for
turn-key high level calls like io.Copy{N}, but considers timeout as being a global
deadline whatever the amount of data being transferred.
Should applications have to deal with significantly heterogeneous transfer sizes,
timeout setting must be adjusted on a per call basis to reflect the more usual "min
bandwidth / max inactivity" concept.
Receiving large chunks takes longer than small ones but this doesn't provides with any
additional information regarding peer's status/health which timeouts are (mostly) useful
for.
There's a golang-nuts thread dedicated to that issue, Russ was hesitating between
deleting the timeout support and making the timeout reset on each byte sent, let's hope
the later is going to win;)
http://groups.google.com/group/golang-nuts/browse_thread/thread/500f3b0e9eed3811/