On Wed, Nov 13, 2013 at 6:21 PM, David Rajchenbach-Teller <dtel...@mozilla.com> wrote: > On Thu Nov 14 00:10:27 2013, Daniel Micay wrote: >>> The only problem is that Linux doesn't really support asynchronously >>> resolving file paths to inodes (aka opening files), but that can be done on >>> a dedicated thread pool, with the advantage that the threads don't do >>> anything, so they don't have zombie stacks. >> >> The file metadata cache is small enough that there's no point in >> considering it blocking. You might as well considering memory accesses >> blocking at that extreme, because they might require fetching memory >> to the CPU cache. > > Are you sure about that? If my memory serves, you still need to fetch it > from disk in most cases. On platforms in which devices have a mechanical > component, even trivial accesses can end up very expensive in case of > disk thrashing and/or sleeping disk. > > Cheers, > David > > -- > David Rajchenbach-Teller, PhD > Performance Team, Mozilla
Mechanical disks are already dead in mobile though, and will be dead elsewhere by the time Rust is widely used. It's normal for all of the metadata to remain in cache, but obviously not page cache. Either way, Linux doesn't expose non-blocking file primitives and (fast) AIO is only a dream at this point. The glibc implementation of POSIX AIO uses threads and blocking I/O. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
