* David Nadlinger added functionality to work around an apparent oddity
of the Windows socket implementation (see WINSOCK_TIMEOUT_SKEW).
Although the hack is documented, I'm a bit uncomfortable with that there
are no provided details or instructions on how to reproduce the
experiments and measurements which led to the inclusion of this hack.
Which kind of »provided details« would be interesting for you? The
WinSock receive timeout duration seems to be be off by half a second on
all Windows boxes I and other helpful people on IRC tested (no personal
firewall/antivirus software/… involved), and that's about it.
A test case is trivial to write, e.g. https://gist.github.com/1211819.
I tried hard to find any official information about the issue, but
except for a few other people having stumbled across the issue, I
couldn't really turn up anything (see e.g.
http://us.generation-nt.com/answer/recv-timeout-so-rcvtimeo-plus-half-second-help-26653302.html).
(There's also the question whether a language library's purpose includes
working around apparent bugs in platforms' implementations.)
If not in the standard library, where else? Granted, the difference is
probably only going to cause problems in unit tests (since actual
programs shouldn't rely on the exact socket timings anyway), but pushing
the burden of writing platform-specific workaround codeto the std.socket
users doesn't seem like a good solution to me either.
David
