On Wed, Nov 13, 2013 at 11:45 AM, Daniel Micay <danielmi...@gmail.com> wrote: > Rust's requirements for asynchronous I/O would be filled well by direct usage > of IOCP on Windows. However, Linux only has solid support for non-blocking > sockets because file operations usually just retrieve a result from cache and > do not truly have to block. This results in libuv being significantly slower > than blocking I/O for most common cases for the sake of scalable socket > servers.
Libuv maintainer here. Libuv's current approach to dealing with blocking I/O is fairly crude: it offloads everything to a rather unsophisticated thread pool. There is plenty of room for improvement. So far relatively little effort has gone into optimizing file I/O because it's not very critical for node.js. I've been looking for an excuse to spend more time on it so please file issues or post suggestions. If you have test cases or benchmarks where libuv is significantly lagging, please point me to them and I'll see what I can do. Apropos IOCP, it's no panacea. It has the same issue that native AIO on Linux has: it can silently turn asynchronous operations into synchronous ones. It's sometimes useful but it's not a general solution for all things AIO. > On modern systems with flash memory, including mobile, there is a *consistent* > and relatively small worst-case latency for accessing data on the disk so > blocking is essentially a non-issue. I'm not sure if I can agree with that. One of the issues with blocking I/O is that the calling thread gets rescheduled when the operation cannot be completed immediately. Depending on workload and system scheduler, it may get penalized when blocking often. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
