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
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Reply via email to