On Mon, Aug 4, 2014 at 6:31 PM, Geert Jansen <[email protected]> wrote: > Hi, > > ever since I first got interested in async IO I have been operating on this > assumption: > > 1. select() on Windows is bad, IOCP is good. > > Since IOCP is completion based, but for polling you need a ready-based API, > I deduced from the above: > > 2. fd/HANDLE/SOCKET polling on Windows is inefficient. > > However, after looking at src/win/poll.c it seems that my assumption #2 is > false because there is a method to get efficient, IOCP based polling to work > on Windows. It appears to be using a super low-level IO control that isn't > even defined in the Windows header files. Libuv calls this "IOCTL_AFD_POLL" > which is "9 | METHOD_BUFFERED". The implementation seems to come from Bert > Belder's "epoll_windows" package. > > First off it is really cool that such an API exists and that Bert found it > (out of curiosity I wonder how). I can't find any reference on this > anywhere. The only reference I found on MSDN is a CVE for a privilege > escalation in AfdPoll which I assume is the same thing. And I found a second > reference in ReactOS which appears to implement this as well. > > Looking through poll.c it seems that the IOCP based poll is called > "fast_poll" and the select based one "slow_poll". Which one is selected > depends on whether getsockopt(SO_PROTOCOL_INFOW) returns a provider that > matches a certain set of GUIDs. > > It would be useful to know when I can expect fast_poll to work and when not. > I'm assuming it depends on the Windows version and other factors too. The > answer is actually pretty important I think because if efficient polling is > readily available on Windows then it becomes waaaay easier to integrate 3rd > party libraries into a libuv based application. Many libraries support being > plugged into an event loop but they want to pass you an FD, and they want to > be called back when it is ready. Without a fast poll, I cannot use this > interface and expect it works efficiently on both Unix and Windows. The > library would need to be able to accept data that is already read via a > memory buffer. The only library I know that supports both FD based IO and > memory buffer based IO is OpenSSL. There might be a few more but I doubt > there are many. All other library that I've seen only supports async IO via > FD polling. > > Can anybody give a clarification on when I can expect fast_poll to work?
When the default WinSock provider is installed and there is no LSP[0] present. Bert explained it to me once a year ago or more but I think that was the gist of it. You can find the proof of concept here[1]. [0] http://en.wikipedia.org/wiki/Layered_Service_Provider [1] https://github.com/piscisaureus/epoll_windows -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
