(Presuming you're referring to this: https://support.microsoft.com/en-us/kb/156932 https://support.microsoft.com/en-us/kb/156932) Those are all entirely reason

(Presuming you're referring to this: https://support.microsoft.com/en-us/kb/156932 https://support.microsoft.com/en-us/kb/156932) Those are all entirely reasonable things to block for if you understand the mechanics behind why those calls may block. And none of it should be fast-path stuff; it's easy to architect a solution where you avoid those things except in corner cases. The other thing you're missing is that when you architect around Windows completion ports and threadpool I/O facilities, it doesn't matter if one thread blocks every so often. Windows will detect this and schedule another one to run, such that there is one active thread scheduled on every core. I/O completion ports facilitate thread-agnostic I/O completion; the thread that blocked because it was extending an encrypted file won't impede the latency of other clients because there is no thread-specific association. I exploit all of this with PyParallel. http://pyparallel.org http://pyparallel.org For more details on asynchronous I/O on Windows and why it's fundamentally better than the UNIX I/O model in every possible way: https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores?slide=47 https://speakerdeck.com/trent/pyparallel-how-we-removed-the-...