On Thu, Nov 14, 2013 at 5:27 AM, Igor Bukanov <[email protected]> wrote: > On 14 November 2013 06:42, Daniel Micay <[email protected]> wrote: >> There's a link to the Microsoft documentation on the >> implementation (replacing Windows fibers) we could be using right now. >> It's not entirely necessary to have it on Linux because threads scale >> well, but it would be nice. > > It is exactly Microsoft that added async keywords to C#. So they know > that UMS does not cover all their needs. Plus various Linux servers > with long-term support (32 bit RedHat 5 is alive and kicking...) make > sure that the need for scalable IO without UMS will exist for a long > time even if UMS will be available with the latest kernels. It also > interesting that both MS documentation and that Google video talk > emphases on compatibility with existing applications and tools and I > doubt that one can both compatibility and optimal performance.
Correct, you won't get optimal performance with 1 task per request/client across every platform. For non-socket I/O, it will be as close as you can get to optimal on Linux except in terms of the huge virtual memory consumption. Due to the differences between platforms, you need a different design to get optimal performance on each (ready-based vs. completion-based, the extent of non-blocking/async support, threading implementation quality, etc.). The performance with 1:1 threading and user-mode scheduling will match M:N threading but it will also be able to simply yield on blocking calls, instead of faking a blocking API for calls without a fast non-blocking alternative. You will get poor performance on Linux with an async/await scheme for anything but sockets compared to the 1:1 user-mode scheduling, and even then it's not a great match for the underlying ready-based API. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
