RE: cURL on Windows with _WIN32_WINNT=0x0600 suffers from WSAPoll bug
Date: Fri, 5 Oct 2012 12:33:00 +0000
On Friday, August 03, 2012, Jan Koen Annot wrote:
> On Wednesday, August 01, 2012, Daniel Stenberg wrote:
> > Is there any official documentation or recognition of this flaw
> > somewhere? A question from 2008 in a forum post is not the most comforting source.
> On August 1, I opened a case for this to Microsoft Premier Online (https://premier.microsoft.com/).
> The support engineer handling my case wrote that the case description is quite clear.
> He will try to reproduce the issue and then proceed with troubleshooting it.
> > What's your suggested fix?
> 3. For Microsoft: repair the bug and publish an update to be installed
Now I can add the following about the reaction of Microsoft regarding the opened case.
1. For Microsoft, it is a known issue:
"Windows 8 Bugs 309411 - WSAPoll does not report failed connections
8/3/2011 6:53 PM Resolved as Won't Fix by muraris
Has been like this forever and people are already used to it."
"The recommendation for now is to not use the WSAPoll function it in case you encounter this issue, but rather the other Net-API functions."
2. I tried to convince Microsoft to solve this bug:
"First, it will cost much time to find out that some 'real-life' issue can be traced back to this WSAPoll bug. In my case we were lucky to have a regression test which triggered when we started using a slightly different cURL-library configuration on Windows. Tracing back that the test was triggered because of this bug in WSAPoll took several hours. Imagine what it would cost, if some customer in the field reported annoying delays, to trace such a vague complaint back to a bug in the WSAPoll function!"
"Second, even if we know beforehand about this bug in WSAPoll, then it is difficult to determine in which situations in your code you can safely use WSAPoll and in which situations you might suffer from this bug. So a better recommendation would be to simply not use WSAPoll. (...)"
"Third, porting code which uses the poll() function to the Windows sockets API is made more complex. The introduction of WSAPoll was meant specifically for this (see http://blogs.msdn.com/b/wndp/archive/2006/10/26/wsapoll.aspx), so it should have compatible behaviour, without a recommendation to not use it in certain circumstances. "
"Fourth, your recommendation will only have effect when actively promoted to developers using WSAPoll. A much better approach would be to repair the bug and publish an update. Microsoft has some nice mechanisms in place for that."
"So, my conclusion is that, even if in our case the business impact may be low because we found the bug in an early stage, it is still important that Microsoft fixes the bug and publishes an update."
3. My arguments could not convince Microsoft to solve this bug:
"A discussion has been conducted around this topic and the taken decision was not to have the fix implemented due to the following reasons:
- This issue since Vista
- no other Microsoft customer has asked for a Hotfix since Vista timeframe
- fixing this old issue might have some application compatibility risk (for those customers who might have somehow taken a dependency on WSAPoll failing with a timeout in the cases of connect failure as opposed to POLLERR).
- This API will become more irrelevant as the Windows versions increase; the networking APIs will move away from classic select/poll to more advanced I/O completion mechanisms."
4. Microsoft leaves a very small possibility that their decision may change:
"The best way to add pressure for a hotfix to be released would be to have the customers reporting it again on http://connect.microsoft.com."
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2012-10-05