On 11/13/13 9:08 PM, Ben Noordhuis wrote: > 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.
If, by any chance, I find time, I would be interested in giving a hand. (I'm the main dev of Mozilla's OS.File) [...] >> 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. Well, for some systems, that's possible, but in the wild, that's not realistic. Firefox Telemetry shows unpredictable worst-case latencies that can be very long (I am talking multi-seconds worst-case, and 800 ms rather common cases). > 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. Is that an issue? I tend to assume that a thread that does I/O should expect being rescheduled often. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
