On Wed, Nov 13, 2013 at 10:46 PM, David Rajchenbach-Teller <dtel...@mozilla.com> wrote: > 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)
That would be great. We hang out in #libuv on freenode.org, drop by for a chat. There is also a mailing list if you prefer that. > [...] >>> 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. Why that assumption? (No snark, I'm genuinely curious.) I reason from a different perspective: the scheduler wants me to use up that time slice it allotted to me and will only suspend me if at some point there is no going forward. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
