3 ms·

Well, apparently not on Windows. But this is a kernel interface issue not a language issue, and clearly needs fixing now we have SSDs where having thousands of

Well, apparently not on Windows. But this is a kernel interface issue not a language issue, and clearly needs fixing now we have SSDs where having thousands of outstanding requests is useful, if not required for performance, unless the hardware APIs are going to change (maybe if they get memory interfaces this does change).

mtanski 11y ago
The async story on windows is better, but not great. In many cases the async calls on windows silently block due to a number of special cases (that are not so special).
- trentnelson 11y ago
  (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-...
trentnelson 11y ago
> Well, apparently not on Windows. Agreed! http://pyparallel.org http://pyparallel.org > But this is a kernel interface issue not a language issue, Absolutely agree! The thing that surprises me most about Rust and Go in particular is that they're trying to solve an OS problem with new language abstractions. You don't need a new language -- what you really want is thread-agnostic I/O primitives, thread-agnostic "threadpool" primitives, and completion-oriented APIs that provide both synchronous and asynchronous primitives. Basically, you want what Windows has.

mtanski 11y ago

The async story on windows is better, but not great. In many cases the async calls on windows silently block due to a number of special cases (that are not so special).

trentnelson 11y ago
(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-...

trentnelson 11y ago

> Well, apparently not on Windows. Agreed! http://pyparallel.org http://pyparallel.org > But this is a kernel interface issue not a language issue, Absolutely agree! The thing that surprises me most about Rust and Go in particular is that they're trying to solve an OS problem with new language abstractions. You don't need a new language -- what you really want is thread-agnostic I/O primitives, thread-agnostic "threadpool" primitives, and completion-oriented APIs that provide both synchronous and asynchronous primitives. Basically, you want what Windows has.