FILE_SKIP_COMPLETION_PORT_ON_SUCCESS and datagram socket read errors

As I mentioned a while back I’ve been looking at incorporating some simple performance gains in the framework by following the advice given over at the Windows Server Performance Team Blog. Specifically the advice from part three of the “Designing Applications for High Performance” series of postings.

Whilst I’d done some quick and dirty tests with the FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag of SetFileCompletionNotificationModes() and all looked good I’m now working my way through my unit tests and adjusting them to work both when this option is enabled and when it’s not (completion dispatch changes somewhat when it’s enabled and my tests are invasive enough to notice this).

I’ve come across a strangeness. I have a test which tests how the framework behaves when you attempt to read a datagram but you don’t supply a big enough buffer. When FILE_SKIP_COMPLETION_PORT_ON_SUCCESS is NOT enabled then I get an error from the I/O completion port; “More data is available”. However, when FILE_SKIP_COMPLETION_PORT_ON_SUCCESS IS enabled the read simply never completes; not even after the socket is closed…

It seems that everything works as expected if there is a read pending before the data arrives; I get the “More data is available” error as expected both when FILE_SKIP_COMPLETION_PORT_ON_SUCCESS is enabled and when it is not. However if there isn’t a read pending when the data arrives then if FILE_SKIP_COMPLETION_PORT_ON_SUCCESS is not enabled I’ll get the “More data” error when I post a read (the error completes though the IOCP and not directly from the call to WSARecv()) and this is as I’d expect, BUT if FILE_SKIP_COMPLETION_PORT_ON_SUCCESS is enabled then the read never completes, not even after the socket is closed…

I need to do some more investigation into this but right now it looks like a fairly serious issue for me and may mean that this performance improvement will NOT be enabled for datagram sockets in 6.2

Updated: 14/01/2010 - the guys over at the Windows Server Performance Blog have confirmed that this behaviour is their bug and not mine.

Updated: 04/04/2013 - it seems that this is now fixed in Windows 8.