On Thu, Nov 14, 2013 at 12:36 AM, Bardur Arantsson <[email protected]> wrote: > On 2013-11-13 23:15, Daniel Micay wrote: >> The issue with async/await is that while it maps very well to the AIO >> primitives like IOCP and POSIX AIO, it doesn't map well to something >> that's solid on Linux. > > Then help fix Linux. (Yes, I'm serious.) > >> It's just not how I/O is done on the platform. >> It uses *non-blocking* I/O so scale up socket servers, with >> notification of ready state rather than completion state. This doesn't >> work for file system access though. >> >> There's a significant performance hit from moving maybe-blocking I/O >> calls into thread pools to fit a square peg into a round hole. >> > > And your proposed solution for this is to force *everything* into a > round hole? > > You'd essentially be forcing every single socket server-type application > to implement their *own* thread pool mechanism. Which (assuming Windows > IOCPs work well) would be suboptimal on Windows and an extra > interoperability concern when sharing code which lives atop a "socket > server". > > The JVM world is actually doing this experiment and it has led to a huge > mess of non-interoperable and non-composable code. I would urge anyone > to *not* follow the same route. > > Regards,
I suggest reading the content I posted to the list then, going into depth about the drawbacks of the current system and how user-mode 1:1 scheduling maintains the same advantages without many of the disadvantages. 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. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
